See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/301282777

GESTION DE PROYECTOS TECNOLOGICOS BASADO EN UN ENFOQUE ITERATIVO

E INCREMENTAL - PROJECT MANAGEMENT BASED ON ITERATIVE AND
INCREMENTAL APPROACH

Working Paper · November 2016

DOI: 10.13140/RG.2.1.2293.0326

CITATIONS READS

0 66

1 author:

Andres Sanchez
Corporación Universidad de la Costa
11 PUBLICATIONS   2 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Framework for Implementation of Process Reengineering in Quality Management Systems for companies in the tertiary sector - Marco de
Implementación de Reingeniería de Procesos en Sistemas de Gestión de Calidad para empresas del sector terciario View project

Design a Quality Management System Document Model under the process metamodel standard SPEM 2.0 metamodel processes in a Free
Software Platform - Diseño de un modelo de Sistema de Gestión de Calidad bajo el estándar de metamodelado de procesos SPEM 2.0 en una
Plataforma Software Libre View project

All content following this page was uploaded by Andres Sanchez on 14 April 2016.

The user has requested enhancement of the downloaded file.

GESTION DE PROYECTOS TECNOLOGICOS BASADO EN UN 
ENFOQUE ITERATIVO E INCREMENTAL

PROJECT MANAGEMENT BASED ON ITERATIVE AND 
INCREMENTAL APPROACH

Ing. Andrés Sánchez Comas
Ingeniero Electrónico de la Corporación Universitaria de la Costa CUC
Grupo de Investigación GIACUC – Centro de Investigación en Innovación de la Región Caribe Colombiana

PALABRAS CLAVES
Gestión del Conocimiento – Gestión de Proyectos – Procesos de Desarrollo – 
Metodologías de Desarrollo – Ciclo de Vida del Proyecto – Equipos de 
Desarrollo – Tecnología – Iterativo e Incremental ­
RESUMEN

La  presente  publicación  tiene  de  base  temática  el  desarrollo  de  proyectos 
tecnológicos  visto  desde  el  contexto  iterativo  e  incremental  ampliamente 
usado  hoy  en  día  por  procesos  de  desarrollo  de  proyectos  de  IT  como  RUP, 
OpenUP, ICONIX y Scrum entre otros; los cuales basan su desarrollo en una 
serie  de  actividades  sucesivas  que  se  repiten  durante  el  ciclo  de  vida  del 
proyecto,  y  que  buscan  desarrollar  el  sistema  como  una  construcción 
sucesiva de partes que a medida que se construyen incrementan las distintas 
funcionalidades que el sistema debe tener. Esta publicación es producto de la 
actividad  investigativa  de  un  trabajo  de  grado  orientado  a  describir  y 
consolidar  el  proceso  de  desarrollo  de  sistemas  embebidos  de  la  empresa 
Bermit Ltda. con sede en Barranquilla Colombia1. Se busca orientar al lector 
con las nociones y conocimientos básicos de la gestión de proyectos iterativa 
e incremental ampliamente usada en la gestión de proyectos tecnológicos de 
hoy en día.

 Proceso de Desarrollo de Hardware de la Empresa Bermit Ltda. Julio 2011 – Corporación Universitaria de la Costa
1
 ABSTRACT

This  publication  is  based  in  the  development  of  technological  projects  from 
the  iterative  and  incremental  approach  used  today  by  processes  of  IT 
development  projects  such  as  RUP,  OpenUP,  Scrum  ICONIX  and  among 
others,  which  base  their  development  on  a  successive  series  of  repetitives 
activities during the project lifecycle and develop the system as a successive 
construction  of  parts  that  increase  as  you  build,  the  different  functions  that 
the system should have. This publication is a product of a research activity of 
construction  of  the  state  of  the  art  of  a  thesis  aimed  to  describe  and 
consolidate  the  process  of  embedded  system  development  process  of 
company  called  Bermit  Ltda.  in  Barranquilla  Colombia.  And  it  basically  want 
to  orient  the  reader  with  the  concepts  and  basic  knowledge  of  iterative  and 
incremental  project  management,  widely  used  in  the  management  of 
technology projects nowday.

INTRODUCCIÓN de  la  Gestión  de  Proyectos  de 

Ingeniería,  numerosas 
En  el  mundo  de  la  Ingeniería  Metodologías  y  Procesos  de 
electrónica,  el  desarrollo  de  Desarrollo,  que  ahondan  esfuerzos 
sistemas  tecnológicos  hace  que  de  en  mitigar  los  impactos  negativos 
la  ejecución  de  cada  proyecto  sea  en  los  esquemas  anteriormente 
único,  en  el  sentido  en  que  el  mencionados, entre muchos otros. 
equipo de desarrollo siempre estará 
enfrentándose  a  nuevos  retos  A continuación se contextualizará la 
planteados  ya  sea  por  las  evolución  de  la  Gestión  de 
necesidades  técnicas  del  sistema  Proyectos de Sistemas Tecnológicos 
que  se  está  desarrollando  en  sí,  o  a  través  de  las  últimas  décadas, 
por  los  requisitos  que  el  cliente  o  para  luego  resaltar  las  principales 
skateholders, u otros puedan exigir  características  de  los  procesos  de 
a  lo  largo  del  ciclo  de  vida  del  desarrollo  RUP,  ICONIX,  y  la 
proyecto,  buscando  siempre  poder  Metodología  SCRUM,  asi  como  la 
cumplir  con  los  esquemas  participación en todo esta temática, 
planificados  de  tiempo,  recursos  y  del  estándar  de  modelado  UML.  Se 
esfuerzos.  Para  lo  anterior,  se  han  analizaran  la  importancia  de  las 
desplegado a lo largo de la historia  herramientas de soporte de gestión 
de  conocimiento  que  pueden  llegar  lograr lo que se quería, incurriendo 
a  dar  apoyo  a  toda  esta  temática,  en sobrecostos y pérdida de tiempo 
se  referenciaran  unos  casos  de  y  esfuerzos,  todo  esto  debido 
éxito  en  los  que  se  usaron  estas  generalmente  al  querer  diseñar  y 
metodologías,  y  finalmente  se  construir el sistema como un todo.
mencionaran  los  principales 
componentes  que  influyen  en  la  Generalmente  en  las  carreras  de 
ejecución de un proyecto los cuales  Ingeniería  Electrónica,  se  enseñan 
fueron identificados en el desarrollo  principalmente  conceptos  y 
del  proyecto  de  grado  fundamentos  de  tecnología,  mas 
anteriormente mencionado. sin  embargo,  estos  no  son 
suficientes  para  un  entorno 
empresarial  en  donde  se  integran 
todos  los  conocimientos  que 
Gestión  de  Proyectos  durante  cinco  años  de  carrera 
Tecnológicos  en  el  profesional  se  forjan  en  la  mente 
pregrado de los profesionales, esto sumado a 
los  nuevos  retos  que  deben 
Durante su paso por el pregrado, el  enfrentar  en  este  sector  que  exige 
autor  de  la  presente  publicación,  resultados  concretos,  hace  que  los 
presenció  y  vivió  que  los  proyectos  de  desarrollo  tecnológico 
desarrollos  de  proyectos  empresariales  no  puedan  ser 
tecnológicos que los estudiantes de  llevados  a  cabo  de  la  manera 
Ingeniería  Electrónica  desarrollan  empírica  como  la  que  los 
durante  su  formación  de  pregrado,  estudiantes  de  Ingeniería  están 
están  enmarcados  de  manera  acostumbrados  a  concebir  en  el 
intuitiva  en  lo  que  a  nivel  mundial  pregrado,  ya  que  lo  que  se  quiere 
es  conocido  como  una  metodología  en el ámbito empresarial es prestar 
de  proyectos  en  cascadas,  la  cual  un  servicio  de  calidad  en  la  que  se 
comprende  básicamente  una  busca principalmente la satisfacción 
secuencia  lineal  de  actividades  en  del cliente y el manejo eficiente de 
bloques,  que  van  desde  el  recursos. Dicho factor de calidad en 
planteamiento  de  la  idea,  la  los  proyectos  de  desarrollo 
planeación  y  el  diseño  para  luego  tecnológicos  está  garantizado  en 
ser  implementado,  creando  en  la  gran  parte  por  la  forma  en  que  se 
gran  mayoría  de  los  proyectos  un  ejecutan  los  proyectos:  costos  lo 
colapso  a  nivel  de  resultados  al  no  más  bajo  posible,  en  el  menor 
tiempo  posible,  y  con  resultados   Incumplimiento  en  las 
orientados al cliente. agendas 

El militar que es considerado padre 
de  la  Gestión  de  Proyectos  es 
Origen  de  la  gestión  de  Bernard  Schiever,  Arquitecto  de 
proyectos Misiles Balísticos Polaris, ya que fue 
este  quien  desarrolló  el  concepto 
En  la  década  de  los  50,  los  de  “concurrencia”  al  integrar  todos 
primeros  en  identificar  esta  área  los  elementos  del  plan  de 
del  conocimiento  tan  importante  desarrollo  del  proyecto  en  un  solo 
hoy en día, así como lo hicieron con  programa  y  presupuesto  [6], 
muchos  otros  adelantos  ejecutándolos  en  paralelo  y  no 
tecnológicos  ha  sido  la  industria  secuencialmente  con  lo  que 
militar  con  el    afán  de  solucionar  y  consiguió  reducir  los  tiempos  de 
optimizar  sus  actividades.  Debido  ejecución  de  los  proyectos  Thor, 
al  desarrollo  de  los  grandes  Atlas y Minuteman.
proyectos  que  estos  llevaban  a 
cabo  se  evidencio  la  necesidad  de  Figura  1.  Factores  de  éxito  en  el 
ámbito  de  la  Gestión  de  Proyectos 
coordinar  los  equipos  y  las 
según Palacios [6]
disciplinas que trabajaban de forma 
simultánea  en  la  construcción  de 
sistemas  requiriendo  el  trabajo 
concurrente  y  la  sincronización  de 
múltiples  ingenierías,  lo  que  llevo 
para los años 60 [6], a los primeros 
pininos  en  la  elaboración  de 
módulos  de  organización  y  gestión 
para  evitar  los  problemas  que 
comúnmente  se  aparecían  en  los 
proyectos [6]:

 Sistemas  disfuncionales  o 
deficientes
 Sobrecostos  en  el 
presupuesto
La  industria  automotriz  fue  el  válidas  para  cualquier  proyecto, 
segundo foco de crecimiento que le  logrando  desarrollar  metodologías 
dio  el  impulso  que  necesitaba  esta  que hoy en día llevan sus nombres 
disciplina  para  surgir  de  la  manera  [6].
como la conocemos, ya que es bien 
reconocido  el  potencial  dado  por  Así  entonces  el  nacimiento  de  la 
esta  industria  a  los  procesos  de  gestión  de  proyectos  arrojó 
gestión  industrial  y  de  producción  conclusiones  sobre  patrones 
en  los  cuales  cae  la  Gestión  de  comunes resumidos en tres puntos, 
Proyectos.  Así  surgieron  de  esta  demostrando que [6]:
pujante  industria  de  ese  entonces 
 Es  posible  determinar  los 
técnicas  como  cronograma, 
costes de nuevos proyectos a 
histograma, el concepto de ciclo de 
partir  de  la  información  de 
vida  del  proyecto  y  la 
antiguos proyectos.
descomposición  en  tareas  (WBS 
 Existen  regularidades  en 
Work Break Down Structure) [6].
todos los proyectos.
Paralelamente  en  los  años  50,   Es  absolutamente  necesario 
Meter Norden en los laboratorios de  descomponer  los  proyectos 
investigación  de  IBM  identifico  la  en  partes  de  decisiones 
necesidad  de  descomponer  y  pequeñas  para  realizar 
planificar  el  trabajo  de  desarrollo  planificaciones.
de  sistemas  computaciones 
complejos  con  el  fin  de  evitar  Ámbito  General  de  la 
Desbordamiento  de  agendas,  de  gestión de proyectos
costes  y  asegurar  el  resultado  de 
calidad  sobre  el  producto,  Cualquier  proceso  ya  sea 
características  estas  que  son  productivo  o  administrativo  puede 
extremadamente  similares  a  las  tomar  la  forma  de  proyecto,  la 
encontradas  por  la  industria  militar  prestación  de  un  servicio,  la 
mencionada  anteriormente,  las  fabricación  de  productos,  e  incluso 
cuales han llegado a  construir para  la  misma  organización  de  la 
hoy  en  día  patrones  de  empresa.  Esto  debido  a  que  según 
comportamiento  comunes  a  todos  Palacio y Ruata [7]:
los  proyectos  con  bases  de 
 Son realizadas por personas.
conocimiento  que  sustentan  con 
 Emplean recursos limitados.
suficiente  información  las  practicas 
  Llevan a acabo estrategias de  previsibilidad  en  la  construcción  de 
actuación. grandes sistemas, con garantías de 
que  el  producto  final  se  obtendrá 
Con  lo  anterior  consideremos  en  el  tiempo  y  con  el  coste 
entonces  un  proyecto  como  la  previamente  estimado”  Así  desde 
ejecución  de  un  trabajo  que  sus  inicios  la  Gestión  de  Proyectos 
además  de  requerir  recursos,  empezó  a  determinar  del  producto 
personas  y  una  ejecución  final,  ¿Que  hay  que  construir? 
controlada,  se  desarrolla  en  un  detallando  entonces  el  resultado 
marco  temporal  preestablecido.  con  amplios  y  complejos 
Así,  la  definición  clásica  de  superdocumentados  de  requisitos, 
proyecto según Palacio y Ruata [7]  tratando de estimar fechas y costes 
es: pre­estimados,  detallando  un  plan 
de  proyecto  y  buscando  identificar 
“Un  conjunto  único  de  actividades 
las  nuevas  tareas  y  recursos  a 
necesarias  para  producir  un 
utilizar,  diseñando  el  plan  de 
resultado  definido  en  un  rango  de 
coordinación  y  ejecución  del 
fechas  determinadas  y  con  una 
proyecto,  todo  esto  buscando 
asignación específica de recursos”.
supervisar  y  coordinar  la  ejecución 
para evitar desviaciones en el plan.
Lo  anterior  puede  ser  el  diseño  de 
un  computador  portátil,  el  Figura  2  Gestión  de  Proyectos 
desarrollo  de  un  software,  la  predictiva [7]
implementación de una nueva línea 
de  producción,  el  diseño  y 
ejecución  de  una  compañía  de 
marketing, etc.

Principios  de  la  gestión  de 

proyectos, nacimiento de la 
corriente  clásica  o 
predictiva.

Según Juan Palacio [6], “La gestión 
de  proyectos  nació  para  ofrecer 
El  principal  objetivo  de  esta  Figura 3 Modelo en cascada [7] 
tendencia “predictiva” era que todo 
resultara  según  lo  previsto 
buscando  cumplir  con  las  agendas, 
Una  Fase  para  cada  departamento 
los  costos  y  la  calidad,  asumiendo 
con  equipos  especializados  y 
parámetros como [6]:
profesionales  especializados. 
Prácticamente  el  producto  se 
 El  proyecto  se  desarrolla  en 
realizaba  como  una  carrera  de 
un  entorno  estable  y 
relevos  en  la  que  el  personal 
predecible.
especialista  pasaba  el  producto  al 
 El  objetivo  es  mantener  el 
personal  siguiente  avanzando 
cronograma,  presupuesto  y 
secuencialmente  a  través  de  las 
recursos.
fases  (creación  del  concepto­
 Divide  el  desarrollo  en  fases 
marketing,  pruebas  de  viabilidad­
que  juntas  determinan  el 
investigación,  diseño  del  producto­
“ciclo  de  vida”  como 
ingeniería,  diseño  del  proceso­
concepto,  requisito,  diseño, 
gestión de proyectos, desarrollo del 
planificación,  desarrollo  y 
prototipo­producción), 
cierre.
considerándose  esta  corriente 
Años  80,  Modelo  en  todavía  como  una  tendencia 
predictiva [7].
Cascada

Así  era  denominado  en  ese 

entonces  esta  corriente  de  la 
Inicios de una transición
gestión  de  proyectos  que  buscada 
dividir  el  proyecto  en  fases  que  se  Pero  para  la  misma  época  de  los 
ejecutaban  de  manera  secuencial  80,  La  publicación  de  “The  New 
donde  cada  fase  era  realizada  por  Product  Development  Game”2  [8] 
personal especializado [7]. en  el  año  1986  ha  marcado  el 
punto de inicio de una nueva forma 
de gestionar proyectos en entornos 

2 Título del artículo publicado en 1986 por Hirotaka 
Takeuchi e Ikujijo Nonaka; que a su vez daba 
continuación a otro de los mismos autores junto con 
Kenichi Imai: 
“Managing the New Product Development Process: 
How Japanese Companies Learn and Unlearn”.
rápidos  e  inestables,  los  cuales  la  especialidad  del  recurso  o  el 
eran  susceptibles  al  fracaso  en  la  personal,  sino  que  notaron  que 
gestión de proyectos predictiva aun  estas  contaban  con  un  equipo 
cuando esta estaba alcanzando una  multidisciplinario  que  trabajaba 
cierta  madurez.  Los  autores  del  conjuntamente  mediante  una 
artículo  observaron  que  algunas  constante  interacción  desde  el 
empresas,  en  mercados  muy  principio del proyecto hasta el final. 
competitivos,  relacionados  con  Parte  del  resultado  de  esta 
productos  de  vanguardia  investigación  terminaría  derivando 
tecnológica,  trabajaban  ignorando  en  la  metodología  de  proyectos 
esa teoría [7]. SCRUM  de  la  cual  se  habla  más 
adelante [7].
Esto  fue  en  empresas 
norteamericanas  y  japonesas  que 
producían  tecnologías  de  primera 
línea  con  características  Nacimiento  de  dos 
innovadoras  y  menor  tiempo  de  corrientes
salida  al  mercado  de  los  nuevos 
productos  en  las  que  Hirotaka  y  Para  el  año  de  1990  el  modelo  en 
Ikujijo  analizaron  específicamente  cascada actuaba como una bola de 
[8]: nieve,  a  medida  que  transcurría  el 
proyecto,  el  riesgo  de  fallar  se 
 La  fotocopiadora  Fuji­Xerox  hacía  grande  y  más  grande  debido 
FX­3500. (1978). a  la  falta  de  retroalimentación  de 
 La  copiadora  personal  Canon  las  partes  del  proceso  durante  el 
PC­10 (1982). proceso,  llevando  a  grandes 
 El coche urbano de 1200cc de  impactos  económicos  y  de 
Honda (1981). esfuerzos.  En  contraprestación  a 
 El  ordenador  personal  NEC  esto  nació  el  modelo  iterativo  e 
PC 8000 (1979). incremental  [9]  en  donde  el 
 La  cámara  Cannon  AE­1  proyecto  no  era  dividido  en  fases 
(1976). especializadas  sino  en  partes  de 
 Cámara  Cannon  Auto  Boy  construcción  del  producto,  cada 
(1979). parte  la  cual  pasaba  por  las  fases 
del proyecto (típicas del modelo en 
Estas  empresas  no  tenían  un  flujo  cascada  generalmente), 
de trabajo en cascada divididos por  desarrollándose  el  producto  del 
proyecto poco a poco, controlando,  enfocado a detectar defectos en las 
y  previendo  el  desarrollo  y  fases  iniciales  y  reducir  el  número 
minimizando  “en  tiempo  real”  el  de  cambios  en  la  planeación  del 
riesgo del proyecto. proyecto  tanto  como  sea  posible, 
intentando  anticiparse  a  futuras 
Para  la  década  de  1990  este  necesidades  buscando  realizar 
modelo  iterativo  e  incremental  etapas  de  análisis  y  diseño  tan 
proveniente  del  Modelo  en  Espiral  completas  como  sea  posible. 
definido  por  primera  vez  por  Barry  Mientras  que  las  características  de 
Boehm  en  1988  enfocado  más  que  las  Metodologías  Agiles  pueden 
todo  a  la  Ingeniería  de  Software  verse  claramente  definida  e 
[10],  resultaría  en  las  dos  grandes  identificadas  en  lo  que  es  llamado 
corrientes  de  metodologías  de  el Manifiesto Ágil (ver ANEXO A).
desarrollos  de  proyectos  IT,  La 
metodologías  Agiles  y  la 
metodología  tradicional.  El  primero 
representado  hoy  en  día  por  una  Diferencia  entre  las  dos 
varios  procesos  de  desarrollo  entre  corrientes  metodológicas 
los cuales están Scrum [5], ICONIX  (Tradicional  y  Ágil)  desde 
[2],  XP  [11]  y  Dynamic  System 
una perspectiva Ágil.
Development  Method  [12]  entre 
otros, y el segundo por su máximo  Figura  4  Comparación  Desarrollo 
exponente el Proceso Unificado. Tradicional y Desarrollo Ágil [6].

Según  los  autores  del  Proceso 

Unificado de Desarrollo de Software 
[9]  ,  esta  metodología  tradicional 
fomentada  se  identifica  bajo  tres 
características principales:

 Dirigida por casos de uso.
 Centrado en la arquitectura.
 Iterativo e incremental.

Además  de  ser  una  metodología 

predispuesta  a  un  levantamiento 
exhaustivo  de  los  requisitos  y 
control  exhaustivo  de  la  calidad 
 integración;  y  se  ejecutarían  de 
forma  secuencial,  pasan  a  tareas 
que  se  llevan  a  cabo  en  el 
momento  que  hacen  falta. 
Normalmente  a  lo  largo  de 
pequeñas  iteraciones  durante  todo 
el desarrollo [6].

No  se  espera  a  disponer  de 

requisitos  detallados  para 
comenzar  el  análisis,  ni  a  tener 
éste  para  pasar  a  la  codificación. 
Muchas  veces  los  requisitos  no  se 
pueden  conocer  si  no  avanza  el 
desarrollo  y  se  va  viendo  y 
Una  de  las  grandes  características  “tocando”  los  resultados.  Otras 
distintivas  entre  estas  dos  veces el mercado es tan rápido que 
metodologías  es  que  los  procesos  a mitad de trabajo las tendencias o 
agiles  no  son  realizados  por  la  competencia  obligarán  a 
equipos diferentes y especializados,  modificar el producto por lo que en 
sino  por  un  equipo  único,  formado  estos  casos  seguir  apegado  a  un 
por  personas  muy  competentes,  plan  de  ejecución  del  producto 
con  perfiles  y  conocimientos  que  seria  irrisorio.  Además,  la 
cubren  las  disciplinas  necesarias  participación  de  todo  el  equipo  en 
para llevar a cabo el trabajo [6]. el  diseño  aporta  gran  cantidad  de 
talento  innovador;  un  valor  clave 
En  el  desarrollo  ágil  no  hay  fases.  en  el  mercado  de  productos  y 
En  realidad  las  fases  pasan  a  ser  servicios TIC [6].
tareas  que  se  ejecutan  cuando  se 
necesitan.  No  se  hace  primero  el  Los  equipos  ágiles  empiezan  a 
diseño  del  concepto  o  los  trabajar  sin  conocer  con  detalle 
requisitos,  más  tarde  el  análisis,  cómo será el producto final. Parten 
luego  el  desarrollo,  etc.  Lo  que  de  la  visión  general,  y  sobre  ella, 
aplicado al software serían las fases  producen  regularmente 
de:  requisitos  del  sistema,  incrementos  de  funcionalidad  que 
requisitos  del  software,  análisis,  incrementan  el  valor  al  producto 
diseño,  construcción,  pruebas  e  [6].
Figura  5  Conceptualización  del  está  basado  en  componentes 
Proceso Unificado [9]. interconectados  a  través  de 
interfaces  bien  definidas, 
basándose  en  tres  principios 
básicos: Dirigido por Casos de Uso, 
PROCESO ÁGILES Y 
Centrado  en  la  Arquitectura,  e 
CLÁSICOS
Iterativo e Incremental.
PU (Proceso Unificado)
Dirigido por los Casos de Uso
Según  Jacobson,  Grady  y  Booch, 
autores  de  este  Proceso  de  Ya  que  lo  que  se  busca  en  el 
Desarrollo,  este  es  considerado  resultado  final  del  proyecto  es 
como  el  conjunto  de  actividades  cumplir  con  los  requisitos  del 
necesarias  para  transformar  los  cliente,  se  plasma  lo  que  los 
requisitos  de  un  usuario  en  un  futuros  usuarios  desean  y 
sistema de software, llegando a ser  necesitan  en  casos  de  uso3  que 
un  marco  de  trabajo  genérico  que  representan a la final, los requisitos 
puede especializarse para una gran  funcionales  y  que  en  conjunto 
variedad  de  sistemas  de  software,  constituyen  el  modelo  de  casos  de 
para diferentes áreas de aplicación,  uso.
diferentes  tipos  de  organizaciones, 
niveles  de  aptitud  y  diferentes  Basándose  en  dicho  modelo  y  a 
tamaños  de  proyecto.  A  través de un conjunto de tareas, se 
continuación  en  el  resto  del  ítem,  crean  unos  modelos  de  diseño  e 
veremos  más  a  fondo  de  que  se  implementación  los  cuales  llevan  a 
trata el Proceso Unificado según los  cabo  los  Desarrolladores  buscando 
autores  del  Proceso  Unificado  ser  siempre  conformes  con  el 
tomado  del  libro  “El  Proceso  modelo  de  casos  de  uso  y  la 
Unificado  de  Desarrollo  de 
3 Es una serie sucesiva de interacciones ocurridas 
Software”[9]. 
entre un sistema y sus actores en respuesta a un 
evento que inicia un actor principal sobre el propio 
El  proceso  unificado  toma  como  sistema. Hace parte de la notación UML de los 
base  que  el  sistema  a  construir  Diagramas de Casos de Uso.
arquitectura del sistema. Así, luego  el 5% y 10% de todos los casos de 
de  esto  los  ingenieros  encargados  uso,  pero  son  los  que  constituyen 
prueban  la  implementación  las  funcionalidades  clave  del 
certificando  que  esté  sistema. Así, La forma corresponde 
correctamente  implementada  la  a  la  Arquitectura  y  la  funcionalidad 
funcionalidad  del  caso  de  uso  o  el  a los Casos de Uso. 
grupo de casos de uso que se está 
trabajando  en  el  momento,  es  Iterativo e Incremental
decir, la funcionalidad del cliente.
Dividir  el  proyecto  en  partes  más 
Aunque  el  desarrollo  del  proyecto  pequeñas  o  mini­proyectos  hace  el 
es  guiado  por  los  casos  de  uso,  desarrollo  mucho  más  práctico. 
esto  no  sucede  de  manera  Cada  pequeño  proyecto  es  una 
individual, estos se desarrollan a la  iteración  que  a  la  final  resulta  en 
vez que la arquitectura del sistema,  un incremento en el proyecto. Cada 
siendo  los  casos  de  uso  quienes  iteración  trata  uno  o  más  caso  de 
guían  a  la  arquitectura  y  este  a  su  uso  según  la  necesidad  y 
vez  influye  en  la  selección  de  los  complejidad  de  esto,  y  que  al  ser 
casos de uso. implementados  amplían  la  utilidad 
del  producto  que  se  está 
Centrado en la Arquitectura construyendo,  así  también  se 
tratan primero los casos de uso que 
La  Arquitectura  es  una  perspectiva  impliquen  los  riesgos  más 
del  diseño  completo  con  las  importantes,  mitigando  el  impacto 
características  más  importantes  del proyecto.
resaltadas, dejando minuciosidades 
a  un  lado.  El  Arquitecto,  es  el  rol  A  medida  que  se  desarrollan  las 
encargado  de  diseñarlo,  este  debe  iteraciones  los  desarrolladores  son 
centrase  en  objetivos  adecuados  quienes identifican y especifican los 
como  realización,  capacidad  de  casos  de  uso  relevantes  creando 
adaptación  al  cambio  y  los  diseños  que  le  dan  el  cuerpo  al 
comprensibilidad.  Son  los  sistema  seleccionado  la 
Arquitectos  quienes  deben  trabajar  arquitectura  como  guía, 
sobre  la  comprensión  general  de  implementando  componentes  y 
las  funciones  clave  del  sistema,  es  verificando que estos satisfacen los 
decir  sobre  los  Casos  de  Uso  del  casos de uso, es decir los requisitos 
sistema, los cuales suelen ser entre  funcionales  del  cliente, 
proporcionando  así  la  arquitectura  cuando  han  alcanzado  un  estado 
una  estructura  sobre  la  cual  guiar  predefinido.
las  iteraciones,  mientras  los  casos 
de uso definen los objetos y dirigen  Durante  la  Fase  de  Inicio  se 
el trabajo de cada iteración. desarrolla  el  levantamiento  de  la 
idea del producto final presentando 
al  final  de  esta  fase  el  análisis  del 
Partes del Proceso Unificado negocio  del  producto  en  el  que  se 
tiene  en  cuenta  las  principales 
Ya  que  el  proyecto  se  divide  en  funciones  del  sistema  para  los 
pequeñas  partes  o  iteraciones  que  usuarios  finales,  es  decir,  una  idea 
incrementan  el  desarrollo  del  de  la  arquitectura  del  sistema, 
producto,  estas  iteraciones  se  cuanto  costara  el  desarrollo  del 
agrupan  en  las  llamadas  Fases  del  proyecto  y  cómo  será  el  plan  del 
proceso,  las  cuales  ejecutan  ejecución.
iteraciones  con  patrones  comunes 
en  cuanto  a  las  tareas  ejecutadas,  En  la  Fase  de  Elaboración  se 
las  cuales  están  agrupadas  en  detallan  las  especificaciones  de  la 
Disciplinas. mayoría  de  los  casos  de  uso  del 
sistema  y  se  diseña  la  arquitectura 
Fases del proceso del sistema, al final de esta fase se 
espera  contar  con  la  plantificación 
El  proyecto  se  desarrolla  a  lo  largo 
de  las  actividades  y  la  estimación 
del  tiempo,  este  tiempo  se  divide 
de  los  recursos  necesarios  para 
en  cuatro  fases  específicas:  Inicio, 
terminar  el  proyecto,  en  la  cual 
Elaboración,  Construcción  y 
para  la  finalización  de  este  se 
Despliegue.  Cada  fase  usa  una 
deberá  tener  en  cuenta  la 
secuencia  de  modelos  los  cuales 
estabilidad  de  los  casos  de  uso,  la 
visualizan  el  desarrollo  llevado  a 
definición  final  de  arquitectura  y  si 
cabo  en  las  distintas  fases,  con 
los riesgos están lo suficientemente 
estos  los  directores  y 
controlados  como  para 
desarrolladores  del  proyecto 
comprometer  el  desarrollo  entero 
pueden  descomponerlos  en  las 
en  un  contrato.  En  la  fase  de 
iteraciones  que  implementan  los 
construcción  es  donde  se  crea  el 
casos de uso, finalizando cada fase 
producto,  equivalente  a  añadir  los 
con  un  hito  el  cual  es  determinado 
músculos  a  un  sistema  óseo  (la 
más  que  todo  por  la  disponibilidad 
arquitectura).
de  un  conjunto  de  artefactos 
Figura  5.6.  Estructura  del  Proceso  preocupación  en  el  proyecto.  Estas 
Unificado [9] tareas  están  categorizadas  en 

La  Fase  de  Transición  es  la  que  disciplinas  que  buscan  cumplir 
convierte  al  producto  en  una  objetivos  comunes  que  se 
versión beta. Acá un cierto número  relacionen entre sí. Estas relaciones 
de  usuarios  prueban  el  sistema  e  de  trabajo  entre  las  tareas  se 
informan  de  defectos  y  mejoras  expresan  en  los  flujos  de  trabajo 
que  hay  que  incorporarle  dirigidas  dentro  de  las  disciplinas.  En  RUP 
a  una  totalidad  de  usuarios  y  que  existen  las  llamadas  Disciplinas  de 
generarían  una  mejor  versión  del  Ejecución  y  las  Disciplinas  de 
sistema antes de su entrega final al  Soporte y están dadas así:
cliente.  Es  en  esta  fase  donde  se 
dan  actividades  como  fabricación  y   Modelado del Negocio.
capacitación  del  cliente  para  la   Requisitos.
entrega del producto.  Análisis y Diseño.
 Implementación.
 Prueba.
 Despliegue.
Las disciplinas del proceso  Gestión  de  cambios  y 
configuración.
La  categorización  de  las  tareas 
 Gestión de proyectos.
dentro  de  RUP  resulta  en  las 
 Entorno.
llamadas  disciplinas,  estas 
recopilan  las  tareas  relacionadas 
con una de las principales áreas de 
A  las  disciplinas  de  Ejecución  se busca establecer un acuerdo con 
pertenecen Modelado del Neogocio,  los  clientes  y  otros  interesados  de 
Requisitos,  Análisis  y  Diseño,  lo  que  el  sistema  debería  hacer, 
Implementación,  Prueba  y  proporcionar  a  los  desarrolladores 
Despliegue.  Estas  básicamente  son  un  conocimiento  concreto  de  los 
las  que  definen,  diseñan  y  requisitos  del  cliente,  definir  los 
construyen  el  producto.  Mientras  límites  del  sistema  (delimitarlo), 
que  las  disciplinas  Gestión  de  proporcionar  información  suficiente 
cambios  y  Configuración  y  Gestión  para  planificar  el  las  iteraciones  y 
de Proyectos son las disciplinas que  estimar  el  costo  del  proyecto  así 
dan  soporte  a  la  ejecución  y  como  el  tiempo  de  desarrollo  del 
desarrollo del proyecto. sistema,  además  de  la  importante 
tarea  de  definir  una  interfaz  de 
En la Disciplina de Modelado del  usuario  para  el  sistema  que  se 
Negocio  a  través  de  distintas  construirá,  enfocándose  en  las 
técnica  y  herramientas  se  busca  necesidades  y  los  objetivos  de  los 
entender  el  entorno  sobre  el  cual  interesados y del cliente.
se  va  a  trabajar  con  el  fin  de 
identificar  mejoras  potenciales,  En  la  Disciplina  de  Diseño  se 
evaluar  el  entorno  sobre  el  que  se  procesan  los  productos  de  trabajo 
va  a  desarrollar  el  producto,  de  los  requisitos  con  el  fin  de 
asegurarse  de  que  los  clientes,  especificar  el  diseño  del  sistema  a 
desarrolladores, y otros interesados  desarrollar,  acá  se  busca 
tengan  un  entendimiento  común  evolucionar  a  una  arquitectura 
del objetivo del producto, así como  consolidada  y  adaptar  el  diseño 
también  derivar  o  identificar  los  para  los  ajustes  a  los  entornos  de 
requisitos del sistemas entre otros. implementación  pensando  siempre 
en  obtener  el  máximo  rendimiento 
En la Disciplina de Requisitos se  del sistema.
busca  obtener  las  solicitudes  del 
cliente  de  manera  explícita  y  En  la  Disciplina  de 
transformar  estos  en  un  producto  Implementación  es  donde  se  le 
de trabajo que cubran el ámbito del  da forma al diseño del sistema y se 
sistema que se va a construir y que  busca  explicar  la  forma  en  que 
pueda  proporcionar  los  requisitos  desarrollara,  se  organizaran  y 
detallados  sobre  los  cuales  el  realizaran  las  pruebas  unitarias,  y 
sistema  se  deberá  hacer.  A  la  final  se  definirá  como  se  integraran  los 
componentes, todo con base en los  que  los  productos  de  trabajo 
productos  de  la  disciplina  de  resultante no tenga conflictos entre 
Análisis y Diseño. En esta disciplina  sí,  ya  sea  por  actualización 
se  organizaran,  probaran  y  simultánea,  problemas  de 
desarrollaran  los  componentes  comunicación  entre  el  equipo  de 
como unidades, y se integraran los  desarrollo, o versiones múltiples de 
resultados  producidos  por  los  los  componentes  del  sistema  o  del 
implementadores individuales o por  sistema  como  tal.  También  acá  se 
el equipo de implementación en un  gestionan  los  registros  de 
sistema ejecutable. contabilidad  del  desarrollo  del 
proyecto y se registra la autoría de 
En  la  Disciplina  de  Pruebas  se  los  participantes  en  los  productos 
centra  principalmente  en  la  así  como  otros  datos  relevantes  de 
valoración  o  evaluación  de  la  este tipo concernientes al proyecto. 
calidad  del  producto,  en  términos  Es  por  esto  que  esta  disciplina  es 
de  si  está  o  no  cumpliendo  con  las  constantemente  utilizada  durante 
funcionalidades  de  los  casos  de  todas las fases del proyecto.
uso,  es  decir,  de  los  requisitos  del 
cliente.  Acá  se  busca  documentar  La  planificación  del  proyecto  se  da 
los  defectos  del  sistema,  opinar  en  la  Disciplina  de  Gestión  de 
sobre  las  mejoras  en  la  calidad  del  Proyectos.  Es  donde  se 
producto,  validar  y  demostrar  las  proporcionan  las  directrices  para  la 
suposiciones  efectuadas  en  las  planificación,  ejecución, 
especificaciones  de  diseño  y  supervisión,  selección  y  gestión  de 
requisitos,  con  demostraciones  personal,  gestión  del  presupuesto, 
concretas,  y  validar  los  requisitos  de  contratos,  la  gestión  de  riesgos 
implementados. y  la  planificación  de  las  iteraciones 
del proyecto.
En  la  Disciplina  de 
Configuración  y  Gestión  de  En  la  Disciplina  de  Entorno,  es 
Cambios están agrupadas todas las  donde  se  organizan  los  elementos 
tareas  que  controlan  y  sincronizan  que  proporcionan  el  ambiente  para 
la  evolución  del  conjunto  del  el  desarrollo  del  proyecto  dando 
producto  de  trabajo  que  componen  soporte  al  equipo  de  desarrollo 
al  sistema  en  construcción.  Esta  abarcando  desde  la  infraestructura 
disciplina  aporta  a  evitar  las  hasta las herramientas.
costosas  confusiones  y  garantiza 
 contexto de un modelo de dominio. 
Este  proceso  hace  a  los  casos  de 
ICONIX uso  mucho  más  fácil  para  diseñar, 
probar y estimar.
Iconix  es  una  metodología  de 
desarrollo  de  software  de  tipo  ágil  En  esencia,  el  proceso  Iconix 
minimalista  y  racionalizado  cuyos  describe  el  núcleo  "lógico"  del 
esfuerzos van enfocados en ir de la  proceso  de  análisis  y  modelado  de 
mejor  y  más  rápida  forma  de  los  diseño.  Sin  embargo,  el  proceso 
casos  de  uso  al  código  a  través  de  puede  ser  utilizado  sin  mucha 
un  buen  sistema  de  análisis  y  adaptación  en  proyectos  que 
diseño.  Utiliza  un  subconjunto  siguen  las  directrices  de  proyectos 
esencial de la notación UML, de los  diferentes o metodologías ágiles. El 
14  diagramas  de  que  tiene  UML,  proceso  Iconix  se  divide  en  cuatro 
ICONIX  utiliza  solo  cuatro;  etapas:
proporcionando  requisitos 
suficientes  y  documentación  de  Análisis de Requisitos
diseño  sin  llegar  a  lo  que  es 
Se  realiza  un  levantamiento  de  los 
llamado  parálisis  de  análisis4.  A 
requisitos  del  cliente  a  medida  que 
continuación se hablara del proceso 
se  modela  el  negocio.  Básicamente 
según la perspectiva de los autores 
se  construye  un  glosario  y  un 
en su libro “Use Case Driven Object 
modelo del dominio que definen los 
Modeling with UML” [2].
términos en los que el cliente y los 
La  principal  distinción  de  Iconix  usuarios describen el entorno sobre 
frente  a  los  demás  procesos  de  el  cual  correrá  el  sistema  a 
desarrollo  es  el  uso  del  Análisis  construir. También se describen los 
Robusto,  un  método  para  cerrar  la  procesos  del  negocio  a  los  cuales 
brecha  entre  la  etapa  de  análisis  y  se  les  adjudicaran  los  requisitos 
el  diseño.  El  Análisis  Robusto  que  se  vayan  definiendo  durante 
reduce  la  ambigüedad  en  las  estas  actividades,  buscando 
descripciones  de  los  casos  de  uso,  construir en el proceso un prototipo 
al asegurar que estén escritos en el  de interfaz de usuario para orientar 
y  capturar con mayor precisión los 
4 Situación en la que un análisis o grupo de analistas  requisitos  del  cliente  definiendo  los 
intenta modelar y descubrir todos y a cada uno de 
casos  de  uso  del  sistema.  Al  final 
los problemas a niveles granulares en un desarrollo 
informático. de esta etapa del proyecto se lleva 
a  cabo  el  hito5  Revisión  de  correctamente.  La  revisión  de 
Requisitos,  el  cual  consiste  diseño  preliminar  es  el  puente 
básicamente  en  actividades  de  entre  el  diseño  preliminar  y  las 
revisión  para  asegurarse  que  el  etapas  del  diseño  detallado  para 
texto  de  casos  de  uso  que  se  cada caso de uso.
desarrolló  durante  esta  etapa  del 
proyecto  este  escrito  en  los  Diseño Detallado
términos del dominio.
Durante  esta  etapa  el  proceso 
Análisis y Diseño Preliminar Iconix  usa  el  modelo  de  dominio  y 
el  texto  de  casos  de  uso  para 
Una  vez  que  los  casos  de  uso  han  diseñar    la  arquitectura  del 
sido  identificados,  el  texto  puede  sistema.  Un  diagrama  de  clases  se 
ser  descrito  de  la  manera  cómo  el  produce  a  partir  del  modelo  de 
usuario  y  el  sistema  van  a  dominio y el texto de casos de uso 
interactuar.  Un  análisis  robusto  se  se  utiliza  para  hacer  diagramas  de 
realiza  para  encontrar  posibles  secuencia.  Al  finalizar  la  etapa  de 
errores en el texto de casos de uso,  Diseño  Detallado  se  realiza  el  hito 
y el modelo de dominio se actualiza  de  Revisión  Crítica  de  Diseño,  el 
en  consecuencia.  El  texto  de  casos  cual  busca  asegurarse  de  que  el 
de  uso  es  importante  para  “como”  del  diseño  detallado 
determinar  cómo  los  usuarios  concuerde  con  el  “que” 
interactúan con el sistema previsto.  especificados  en  los 
También  proporcionan  al  analista  requerimientos,  revisar  la  calidad 
con  algo  para  mostrar  al  cliente  y  del  diseño,  revisar  la  continuidad 
verificar  que  los  resultados  de  los  de  los  mensajes  en  los  diagramas 
análisis  de  los  requisitos  son  de  secuencia,  y  revisar  que  las 
correctos.  Luego  de  esta  etapa  se  clases  en  el  diagrama  de  clases 
desarrolla  el  hito  de  Revisión  de    tengan  los  métodos  y  atributos 
Diseño  Preliminar  que  ayuda  a  que  apropiados.
el  diagrama  robusto,  el  modelo  del 
dominio,  y  el  texto  de  caso  de  uso  Implementación.
estén  sincronizados  unos  con  otros   
Se  identifican,  describen  y 
organizan  las  pruebas  unitarias  a 
5 Son momentos dentro del proyecto en que ya se ha  partir  del  cual  se  implementara  el 
logrado cierto estado de avance que simboliza haber 
cuerpo  del  sistema  permaneciendo 
conseguido cierto estado de avance en el proyecto.
siempre  a  la  altura  del  texto  de 
casos  de  uso  y  los  diagramas  de  trabajan  de  manera  amontonada  y 
secuencia.  Por  último  se  escribe  el  apiñada,  empujando  todos  en  la 
código  utilizando  la  clase  y  los  misma dirección.
diagramas  de  secuencia,  como  una 
guía. En  Scrum  la  captura  de  los 
requisitos  para  el  producto  se 
realiza teniendo en cuenta la visión 
del  cliente  y  del  usuario 
SCRUM directamente, y es que estos están 
siempre  inmersos  durante  el 
Es una metodología de trabajo para 
desarrollo  del  proyecto  y  no  al 
el  desarrollo  de  proyectos  de  IT 
inicio  como  la  mayoría  de  los 
que  se  basa  en  el  principio  ágil 
procesos de desarrollo como RUP o 
iterativo  e  incremental,  altamente 
ICONIX.  El  equipo  captura  los 
orientado  al  cambio  en  los 
requisitos  del  cliente  siendo  este 
requisitos  o  prioridades  del  cliente, 
mismo  quien  dicta  que  requisitos 
logrando gestionar los proyectos de 
se  deben  implementar  primero, 
una  forma  mucho  más  ágil.  A 
esto  se  registra  en  unas  Historias 
continuación  se  hace  una 
de  Usuario6  ,  la  cuales  son  unas 
introducción  completa  de  esta 
sencillas  tarjetas  en  las  que  se 
metodología [6][13][14].   
recoge  de  forma  esquemática  y  en 
un  lenguaje  claro  que  es  lo  que  se 
Esta  metodología  se  adapta 
quiere  hacer.  Esas  historias  de 
perfectamente  a  equipos  de 
usuario  se  reúnen  en  una  lista  de 
desarrollo  pequeños  permitiendo 
requisitos  del  producto  que  es 
que  estos  trabajen  de  manera 
llamada  Product  Backlog7,  a  cada 
auto­organizada,  ya  que  se 
presume  que  de  esta  manera  se 
consiguen  más  rápidos  y  mejores  6 Tarjetas que se usan de manera didáctica entre el 
resultados. Estos pequeños equipos  equipo de trabajo y el cliente donde este plasma sus 
por lo general están integrados por  requisitos de manera esquemática y en un lenguaje 
diferentes  disciplinas  profesionales  claro, tratando de resumir el requisito en una frase y 
preferiblemente con un ejemplo genérico.
que  al  estar  auto­organizados 
trabajan  comprometidos  y  auto­ 7 Conjunto de Historias de Usuarios que son 
motivados. Precisamente la palabra  priorizados para ser trabajados dentro un Sprint. Este 
conjunto de Historias de Usuario se consolidan en un 
Scrum  viene  del  vocabulario  del 
documento con el fin de consolidar allí el retorno de 
deporte  Rugby,  y  es  la  figura  en  la inversión del Sprint que va a ser desarrollado, así 
que  los  compañeros  del  equipo  como las estimaciones del esfuerzo requerido, lo que 
historia  de  usuario  el  cliente  le  Jamón”.  La  respuesta  del  cerdo  es 
asigna  una  prioridad  y  el  mismo  una negativa rotunda alegando que 
equipo  es  quien  le  asigna  cuanto  en  ese  caso  el  Pollo  solo  estaría 
tiempo  se  demoraran  cumpliendo  implicado  al  poner  los  huevos  pero 
con el requisito del cliente. él  estaría  comprometido  al  colocar 
el Jamón.
El  tiempo  en  el  cual  el  equipo  de 
desarrollo  se  compromete  a  Siguiendo  lo  anterior  juegan  el 
cumplir  con  el  requisito  de  el  papel de cerditos:
cliente  se  enmarcan  dentro  de  los 
llamados Sprint backlog8 y estos no   El  Product  Owner,  es  el 
deben  tener  una  duración  mayor  a  responsable  de  llevar  y 
4  semanas  y  no  menor  a  2  representar  los  requisitos  del 
semanas.  Los  requisitos  dentro  del  cliente  y  es  quien  aporta  la 
sprint  se  dividen  en  tareas  que  visión  del  producto.  Es  este 
deben  procurar  no  ser  mayores  a  quien  se  encarga  de  escribir 
16  horas,  permitiendo  así  tener  a  las  historias  de  usuario  y 
un  equipo  de  desarrollo  flexible  y  asignarles  las  respectivas 
auto­gestionado,  ya  que  son  ellos  prioridades  ubicándolas  en  la 
mismos  quienes  se  designan  las  lista  de  requisitos  del 
tareas. producto.  Este  puede  ser  ya 
sea  un  trabajador  interno  de 
Los  roles  que  están  inmersos  en  la  empresa  del  equipo  de 
Scrum  se  agrupan  en  dos  grupos:  desarrollo  para  un  nuevo 
Los  cerdos  y  los  pollos.  Esto  viene  producto,  o  en  caso  de  que 
de  la  parodia  de  la  Gallina  le  este representando al cliente. 
propone  al  Cerdo  abrir  un  Básicamente  es  el 
restaurante, y el cerdo le responde  responsable  por  la  viabilidad 
preguntándole  como  sería  el  económica  del  proyecto,  es 
nombre del restaurante, a lo cual el  decir,  que  este  debe  buscar 
pollo  le  responde:  “Huevos  con  siempre  lograr  altos  índices 
del retorno de la inversión.
permitirá al Product Owner ajustar la línea temporal   El  Scrum  Master  o 
del Sprint. facilitador, tiene como papel 
principal liberar de obstáculos 
8 El Sprint Backlog es un documento en el que el 
equipo de desarrollo describe como implementara  y  dificultades  al  resto  del 
las historias de usuario en el siguiente Sprint. equipo  para  que  este  pueda 
 cumplir  a  cabalidad  los  reunión  se  deben  formular 
objetivos del sprint. básicamente 3 preguntas claves:
 El  Equipo  de  Desarrollo, 
quien tiene la responsabilidad   ¿Qué me falta?
de  construir  el  producto.   ¿Cómo lo voy a lograr?
Idealmente  este  equipo   ¿Qué  problemas  has 
debería  ser  de  entre  5  y  9  identificado  que  deben  ser 
personas  de  distintas  sacados  a  la  luz  para  ser 
disciplinas  (analistas,  resueltos  lo  más  pronto 
diseñadores,  desarrolladores,  posible?
etc.)
Uno  de  los  ámbitos  de  admirar  de 
Los  Pollos  son  aquellos  como  los  esta  metodología  es  la 
usuarios  finales,  el  cliente,  los  comunicación  en  tiempo  real  que 
vendedores  del  producto,  y  los  mantiene  el  equipo  ya  que  todos 
gestores  o  directivos  de  la  saben siempre que está haciendo el 
empresa,  quienes  son  los  que  o  equipo  y  como  está  avanzando, 
bien  proporcionan  la  visión  general  para  esto  se  apoya  de 
del  producto,  o  dan  la  aprobación  herramientas  de  la  propia 
para  con  los  resultados  del  metodología  como  lo  es  el 
proyecto. Burndownchart9, el cual consiste en 
un  tablero  que  contiene  el  estado 
Esta  metodología  tiene  como  una  de  las  tareas,  si  están  pendiente, 
de sus principales características la  en proceso o si ya están listas para 
comunicación  continua  entre  los  revisión,  o  si  ya  han  sido 
integrantes  del  equipo,  ya  que  terminadas.
exige  que  se  realicen  reuniones 
diarias  a  una  hora  predefinida  que 
normalmente  son  en  la  mañana, 
para  lo  cual  todo  el  equipo  debe  Lenguajes de Modelado
asistir  puntualmente.  Esta  reunión 
Booch [15], describe la importancia 
debe  durar  alrededor  de  15 
de  modelar  realizando  una 
minutos  y  se  debe  realizar  de  pie 
con  el  fin  de  mantener  el  máximo 
9 Grafica que muestra la cantidad de del Product 
de  atención  y  concentración  en  lo 
Backlog que están pendiente para la fecha de 
que  se  está  hablando.  En  esta  finalización del sprint, lo que le evidencia al equipo el 
avance del proyecto.
comparación  entre  la  construcción  su  familia  podría  quedar  muy 
de  una  casa  para  perros,  la  satisfecha.
construcción de una casa familiar, y 
la  construcción  de  un  edificio  de  Y  si  usted  quiere  construir  un 
negocios.  Al  momento  de  construir  edificio  de  negocios, 
una casa puede usted empezar con  definitivamente  sería  tonto  iniciar 
las  tablas,  clavos  y  unas  cuantas  con  una  pila  de  tablas,  clavos  y 
herramientas,  y  bien  puede  usted  unas  cuantas  herramientas 
iniciar  la  construcción  y  en  un  par  especializadas.  Ya  que 
de  horas  sin  ningún  plano  probablemente  usted  estaría 
especializado  podrá  tener  una  casa  jugando  con  el  dinero  de  otros,  le 
para perros totalmente funcional.  exigirán  forma,  estética,  y 
funcionalidad,    a  menudo  sus 
Ahora,  al  momento  de  construir  clientes  cambiaran  de  opinión  en 
una  casa  para  su  familia,  también  cuanto  a  estos.  Hará  lo  que  usted 
podría  iniciar  con  muchas  más  querrá  también  hacer  extensas 
tablas  de  madera,  clavos,  otros  planeaciones  ya  que  el  riesgo  de 
materiales  más  especializados,  y  pérdida  de  dinero  es  altísimo.  Y 
herramientas  un  tanto  más  mientras  usted  trabaje  con  las 
especializadas.  Ciertamente  con  personas  indicadas,  incluirá  las 
esto  usted  se  tomara  mucho  más  herramientas  indicadas  para  dirigir 
que un par de horas, tal vez un par  el  proceso  de  transformar  el 
de  días  e  incluso  meses.  Entonces,  concepto  arquitectónico  en 
si  usted  quiere  construir  una  casa  realidad, querrá balancear el deseo 
que  cumpla  correctamente  con  las  de  sus  clientes  con  la  construcción 
necesidades  y  gustos  de  su  familia  del  edificio,  disminuyendo  siempre 
y  las  reglamentación  de  el riesgo de tirar a la basura todo lo 
construcción  deberá  dibujar  que habrán construido.
algunos  planos  que  le  permitan 
proyectar de manera razonable que  Entonces  Booch  [15]  describe  que 
deberá  comprar,  que  cantidad  y  si  en  el  desarrollo  de  sistemas  de 
necesitara  o  no  personal  software  muchos  proyectos 
especializado. Y aunque bien podría  pretenden  construir  grandes 
construirlo  usted  solo,  debe  edificios  pero  afrontando  el 
apegarse  a  los  planos  y  desarrollo  como  si  fueran  a   
proyecciones  de  costos  y  tiempos,  construir  una  casa  para  perros. 
Entonces  es  en  los  lenguajes  de 
modelado donde podemos construir  comportamiento  del  entorno  sobre 
los “modelos arquitectónicos de los  el  cual  se  desarrollara  y  construirá 
edificios de negocios” o sistemas de  el  sistema,  los  requisitos  del 
software  que  se  quieren  construir,  cliente, la arquitectura diseñada del 
lo  que  nos  permiten  visualizar  el  sistema, o la evolución y desarrollo 
producto  final  antes  de  iniciar  su  del  proyecto  como  tal,  y  esto  se 
construcción,  permitiendo  hace  sobre  modelos,  los  cuales 
proyectar  la  reutilización  de  buscan  precisamente  eso,  ayudar 
recursos  y  ajustar  el  diseño  a  los  al  manejo  de  la  complejidad  de 
requisitos  del  cliente  y  a  los  grandes  sistemas  o  cantidades  de 
cambios del entorno. información  que  por  lo  general  las 
personas  no  podrían  manejar  en  el 
Este  mismo  autor  define  con  base  contexto  de  sus  entendimientos, 
en todo lo anterior, que un modelo  roles,  y  tareas  específicas  dentro 
es una simplificación de la realidad,  del  proyecto,  por  lo  que  se  busca 
los  cuales  se  construyen  para  que  hacer  más  comprensible  y 
se puedan comprender los sistemas  manejable  dichos  volúmenes  de 
que  se  van  a  desarrollar,  dichos    información  para  el  correcto 
modelos  ayudan  a  visualizar  un  desarrollo de un proyecto. 
sistema  como  debe  ser  o  como  se 
quiere  que  sean,  permiten  Por  lo  general  los  modelos  se 
especificar  la  estructura  de  componen  de  notaciones  de 
comportamiento  de  un  sistema,  diagramas  que  buscan  representar 
dan  guías  y  luces  de  cómo  se  mediante  una  convención  de 
deben  construir,  y  poder  lenguaje gráfico información ya sea 
documentar  las  decisiones  que  se  numérica  o  textual.  A  continuación 
toman  sobre  el  desarrollo  en  el  hablamos  del  lenguaje  más 
producto  final,  y  que  al  final,  ampliamente  utilizado  para  el 
modelamos  sistemas  para  desarrollo de proyectos IT, UML.
comprender la complejidad de tales  
sistemas. UML  (Unificated  Modeling 
Language).
Muchos  procesos  de  desarrollos, 
independientemente  de  la  El  lenguaje  de  modelado  unificado 
metodología,  enfoque  y  filosofía  es  un  lenguaje  de  modelado  visual 
que  usen,  deben  plasmar  o  diseñado  para  construir,  visualizar, 
abstraer  bien  sea,  el  documentar  y  especificar  los 
métodos  o  procesos  de  un  sistema   Diagrama de paquetes.
software  aunque  es  posible 
extenderlo  para  otra  multitud  de  Los  Diagramas  de  Comportamiento 
aplicaciones.  UML  es  considerado  se  enfocan  en  describir  lo  que  el 
ya  un  estándar  a  nivel  mundial  y  sistema  debería  hacer,  es  decir, 
hay  que  aclarar  que  no  es  un  cómo  funciona  el  sistema  o  lo  que 
lenguaje  de  programación  aunque  sucede  en  el  sistema,  y  para  esto 
muchas  herramientas  permiten  hace uso de:
generar  código  o  plantillas  para  la 
 Diagramas de actividades.
construcción  del  código.  A 
 Diagramas de casos de uso.
continuación  se  hará  una 
 Diagramas de estado.
introducción  general  a  esta 
mundialmente  conocida  e 
Los  Diagramas  de  Interacción 
importante  notación  de  modelado 
pueden  considerarse  un 
tomando  como  referente  al  trabajo 
subconjunto  de  los  diagramas  de 
de  los  autores  de  este  estándar, 
comportamiento  ya  que  se 
Jacobson, Grady y Booch [15].
focalizan  en  describir  el  flujo  de 
control  y  de  datos  entre  los 
UML está compuesto por diagramas 
elementos  del  sistema  que  se  está 
con  sus  respectivas  notaciones  y 
modelando, a estos pertenecen:
están  agrupados  en  tres  grandes 
grupos  Diagramas  de  estructuras, 
 Diagramas de secuencia.
Diagramas  de  Comportamiento  y 
 Diagramas de comunicación.
Diagramas de Interacción.
 Diagramas de tiempo.
 Diagramas  globales  de 
Los  Diagramas  de  Estructura  se 
concentran  en  modelar  y  definir  interacción  o  Diagrama  de 
elementos  que  deben  existir  en  un  vista de interacción.
sistema,  de  este  grupo  hacen 
A  continuación  definiremos  los 
parte:
diagramas usados comúnmente.
 Diagramas de clases.
 Diagramas de componentes.
 Diagramas de objetos.  Diagrama  de  Clases:  Para 
 Diagramas de despliegue. la  construcción  del  modelo 
 Diagramas  de  estructura  del  dominio  que  busca 
compuesta. describir  la  relación  entre  los 
 objetos  del  mundo  real  en  muestra  como  está  dividido 
términos  de  “tiene  un”  y  “es  lógicamente  el  sistema  en 
un”.  Y  para  el  modelo  de  agrupaciones  mostrando  las 
clases  sobre  el  cual  se  respectivas  dependencias 
construirá  el  código  del  entre los paquetes.
sistema  para  el  área  del   Diagrama  de  Secuencia: 
software. utilizados  para  asignar  los 
 Diagrama  de  Actividades:  métodos  identificados 
Para  modelar  el  negocio  durante  la  construcción  del 
sobre  el  cual  se  ejecutara  el  Diagrama  Robusto,  a  las 
sistema  a  construir  y  gracias  clases  del  modelo  de  clases. 
al  cual  se  identifican  los  Es  decir,  le  asigna  el 
casos de uso del negocio que  comportamiento  debido  a  las 
sirven  para  identificar  las  clases con el fin de darle una 
mejoras  que  se  le  harán  al  personalidad  al  sistema  que 
sistema,  además  de  buscar  se está modelando.
conocer  de  manera  detallada 
el  comportamiento  del   Diagrama  de  requisitos: 
negocio. Donde  se  plasman  los 
 Diagrama  de  Casos  de  requisitos  del  sistema  y  se 
Uso:  En  este  se  plasman  las  construye  la  relación  unos 
funcionalidades  que  debe  con  otros  y  a  partir  del  cual 
tener  el  sistema  sobre  los  se asignan a los casos de uso 
casos  de  usos,  y  con  el  cual  del  sistema,  clases,  y  otros. 
se  crean  las  relaciones  de  Este  diagrama  es  originario 
cómo se comportan los casos  del lenguaje de especificación 
de  uso  unos  con  respectos  a  de  sistemas  SysLM  (system 
otros.  Por  lo  general  se  Lenguage  Modeling  por  sus 
utilizan  las  relaciones  siglas en ingles)10.
“invoca” y “precede” para ver   Diagrama  Robusto,  es  un 
cómo  interactúan  los  casos  diagrama  especial  diseñado 
de usos. por  el  proceso  Iconix  con  el 
 Diagrama  de  Paquetes: 
para  abstraer  la  complejidad   SysLM es un lenguaje de modelado avalado por la 
10

del  sistema  en  la  OMG (Object Management Group) y actualmente 

esta en la V1.2. mayores detalles: 
construcción  de  la 
http://www.sysml.org/docs/specs/OMGSysML‐v1.2‐
arquitectura del sistema. Este  10‐06‐02.pdf
 fin  de  identificar  las  clases  A  continuación  detallamos  los 
del  sistema,  eliminar  las  conceptos  de  los  sistemas 
ambigüedades del modelo del  informáticos  generalmente  usados 
dominio,  e  identificar  los  para el manejo de proyectos.
métodos y operaciones de las 
clases. ALM  Systems  (Aplication 
Lifecicle Management system)

Según Perz, Durn y Bernadez en su 
ESTADO ACTUAL  artículo  “Fundamentos  para  un 
(CIENTÍFICO Y  Entrono  de  Application  Lifecycle 
Dirigido  por  Procesos”  [16]  ,  los 
TECNOLÓGICO)
sistemas  de  administración  para  el 
Herramientas  soporte  para  el 
ciclo de vida del proyecto se basan 
Desarrollo de Proyectos
en  herramientas  que  facilitan  el 
Durante  el  desarrollo  de  este  desarrollo  en  numerosas  áreas  de 
proyecto de grado, se identifico que  trabajo  como  la  integración  de  la 
en  el  desarrollo  de  proyectos  captura  de  requisitos,  diseño  de  la 
tecnológicos,  además  de  tener  una  arquitectura,  codificación,  prueba  y 
serie  de  tareas  sucesivas,  otros.  Estos  sistemas  ayudan  a 
organizadas  y  focalizadas,  es  incrementar  la  productividad  al 
apoyado  por  herramientas  poder  compartir  la  información  con 
informaticas  que  son  capaces  de  todo  el  equipo  permitiendo  que  los 
brindar  todo  el  soporte  necesario  distintos  roles  participantes  se 
para  llevar  de  manera  más  enfoquen  en  el  área  de  proyecto 
eficiente  la  información  del  que  le  es  pertinente  y  hacer  la 
proyecto  permitiendo  documentar,  trazabilidad  a  las  demás  áreas  del 
consultar, proyectar, representar  y  proyecto.  Incrementan  la  calidad 
procesar  la  gran  cantidad  que  en  del  producto  permitiendo  llevar  la 
un  proyecto  se  puede  llegar  a  información desde los esbozos de la 
generar  y  que  ha  permitido  llevar  ideas  del  cliente  hasta  el  modelo 
de  manera  eficiente  y  óptima  la  detallado  del  producto  final.  Ayuda 
ejecución  de  proyectos  de  grandes  a  acelerar  el  desarrollo 
envergaduras  yendo  desde  el  simplificando  la  integración  de  la 
manejo  de  la  información  y  la  información  permitiendo  hacer  un 
gestión  del  personal,  hasta  la  trabajo  más  colaborativo  entre  los 
proyección y gerencia del proyecto.  integrantes  del  equipo  de 
desarrollo. Disminuye los costos de  todas  las  fases  del  proyecto,  y 
desarrollo  sincronizando  siempre  el  permiten  la  reutilización  del 
diseño  y  la  aplicación  final.  Y  software,  portabilidad  y 
aumentan la flexibilidad reduciendo  estandarización.
el  tiempo  en  el  que  se  adaptan  las 
aplicaciones  que  soportan  las  KMS  (Knowledge  Management 
nuevas  iniciativas  del  negocio.  Así  system)
también,  los  anteriores  autores 
Según  Becerra  y  Saberwai  en  su 
categorizan  los  sistemas  ALM 
libro  “Knowledge  Management 
como:
Systems  and  Process”  [17],  los 
 Gestores de Tareas. Sistemas Gestores de Conocimiento 
 Manejos de flujos de trabajo. son aplicaciones software utilizados 
 Supervisión y reportes. comúnmente  en  el  desarrollo  de 
 Implementación de Software. proyectos  para  la  generación  de 
 Análisis de requisitos. contenido  de  información  a  través 
 Gestores de requisitos. de  las  distintas  fases  en  la  que 
 Diseño. transcurre  el  proyecto.  Durante  el 
 Modelado. desarrollo  del  proyecto  es  casi  que 
 Gestores de cambios. mandatorio  generar  cantidades  de 
 Gestores de proyectos. información  que  van  desde  el 
 Software de Pruebas. modelado  de  los  procesos  del 
negocio,  la  captura  de  requisitos, 
Entre  los  beneficios  más  notorios  generación de nuevo conocimiento, 
de  esta  herramienta  podemos  análisis  y  procesamiento  de 
encontrar  el  aumento  en  la  calidad  información  para  su  utilización  en 
del  producto,  la  reducción  de  distintas  áreas  y  fases  del 
costos  y  tiempos,  mejoras  en  la  proyecto,  toma  de  decisiones, 
planificación, aumento de las bases  revisiones,  aprobaciones,  informes 
de  conocimiento  de  una  empresa,  y  otros,  que  si  se  manejaran  de  la 
automatización  del  desarrollo  del  manera  tradicional,  individual  y 
software,  documentación  y  descentralizada  como  las 
generación  del  código  así  como  de  organizaciones  están 
las  pruebas  y  la  gestión  del  acostumbradas  a  realizarlo, 
proyecto,  facilitan  el  uso  de  las  causarían una deficiente gestión de 
distintas metodologías propias de la  la  información  tanto  en  los 
ingeniería  del  software,  gestión  en  proyectos  de  grandes  magnitudes 
como  los  sencillos,  llegando  a  personas,  artefactos  u 
producir  atrasos,  pérdidas  de  organizaciones.
tiempo  y  sobrecostos  en  los   Knowledge  Discovery 
procesos administrativos. systems:  Sistemas  para  el 
descubrimiento  del 
Podemos  describir  una  conocimiento  que  soportan 
categorización  de  los  KMS  según  procesos  de  desarrollo  de 
[17]: nuevo  conocimiento  tácito  o 
explícito  de  datos 
 Knowledge  Applications 
provenientes  de  grandes 
Systems:  los  sistemas  para 
volúmenes de información.
la aplicación del conocimiento 
 Knowledge  Sharing 
son  plataformas  o 
Systems:  Sistemas  de 
aplicaciones  dentro  de  una 
socialización  del 
organización  que  ayudan  a 
conocimientos  que  soportan 
utilizar  el  conocimiento  que 
el proceso a través del cual el 
normalmente  está  en 
conocimiento  es  comunicado 
posesión  de  unas  pocas 
y  compartido  a  otros 
personas  al  interior  de  una 
individuos de la organización.
organización  o  grupo,  y  que 
ha  sido  capturado  Issue Trackinng Systems
previamente  para  que  otras 
personas  puedan  utilizarlo  de  Janak  [18]  en  su  tesis  define  los 
manera  explícita  sin  sistemas  de  gestión  de  incidencias 
necesidad  de  entender  también  denominados  Trouble 
plenamente  en  que  consiste  Ticket  System  o  Incident  ticket 
dicho  conocimiento  con  el  fin  System,  son  software 
de  cumplir  con  objetivos  especializados  en  la  gestión  de 
específicos. tareas,  seguimiento  de  errores, 
 Knowledge  Capture  gestión  y  manejo  de  incidencias,  y 
Systems:  Sistemas  de  en  general  para  la  gestión  de 
capturas  del  conocimiento,  proyectos  que  pueden  ir  mas  allá 
que  soportan  el  proceso  de  de  proyectos  de  tipo  software 
recopilación  y  recuperación  permitiendo  adentrarse  en  áreas 
de  conocimiento  tácito  o  administrativas y de gestión dentro 
explicito  que  reside  en  las  de una organización.
Según  Janak  [18]  En  el  desarrollo  transporte  de  mercancía  y 
de  proyectos  de  IT  los  Issue  pasajeros.  Este  proyecto  se  viene 
Tracking  Systems  por  lo  general  desarrollando  desde  el  año  2001 
permiten: con el fin de optimizar y maximizar 
la  capacidad  de  transporte  de 
 Compartir  información  con  el  mercancía  y  pasajeros  a  través  de 
equipo de desarrollo los  cuatro  medios  de  transporte 
 Tener  una  vista  general  del  más  grandes  del  país,  aire,  tierra, 
estado del proyecto agua y rieles. Para este proyecto se 
 Establecer  y  actualizar  la  ha  usado  como  guía  en  el 
importancia  de  las  desarrollo  del  proyecto  al  proceso 
incidencias. RUP, realizando actividades propias 
 Tener  un  histórico  de  de  este  proceso  como  la 
cambios. identificación  de  los  roles  y 
 Recordar  lo  que  debe  ser  skateholders  en  el  dominio  del 
ajustado, creado, modificado,  transporte,  un  modelo  de 
o desarrollado. referencia  que  describe  los 
 Saber  quién  reportó,  cuándo  subdominios  del  dominio  del 
y  qué  petición,  confirmación,  transporte,  una  vista  funcional  que 
análisis  e  implementación  de  describe  la  descomposición  de  la 
alguna  solución  fue  estructura  funcional  de  los 
implementada. subdominios,  una  vista  de 
 Que  cambios  han  sido  comportamiento  describiendo  los 
realizados  y  cuánto  tiempo  escenarios  y  las  relaciones  entre 
tomo  la  resolución  de  alguna  los  subdominios,  y  una  vista  de 
incidencia. información  describiendo  modelos 
de  información  conceptual  para  el 
transporte  de  carga  multimodal 
[19].
Casos de éxito con 
Procesos de Desarrollo Designing  the  Large  Synoptic 
Proyecto Arktrans Survey  Telescope’s  Image 
Processing Pipeline
El  gobierno  noruego  desarrolla  el 
proyecto  Arktrans,  una  plataforma  Mediante  el  proceso  ICONIX  se 
tecnológica  para  el  soporte  de  logró  realizar  el  mejoramiento  del 
transporte  multimodal  para  el  sistema  de  procesamiento  de 
imágenes  del  telescopio  Large  El  Departamento  de  Automotores 
Synoptic  Survey  Telescope  ubicado  del  Estado  de  Virginia  en  Estados 
al norte de Chile el pico “El Pechón”  Unidos es una agencia del gobierno 
en  el  monte  de  Cerro  Pachón,  a  encargada de administrar el parque 
2682 metros sobre el nivel del mar.  automotor  del  estado  así  como  los 
Los  directores  del  proyecto  de  impuestos  relacionados  en 
mejoramiento  fueron  los  gurús  en  beneficio  de  los  ciudadanos  del 
el  proceso  de  desarrollo  Iconix,  estado  mismo  regulando  también 
Doug  Rosenberg  y  Math  Stephens.  las  licencias  de  conducciones, 
De  este  proceso  se  destacan  los  titulación  del  parque  automotor, 
resultados  óptimos  obtenidos  seguridad  en  el  transporte,  y  la 
teniendo  en  cuenta  que  por  la  regulación de las leyes relacionadas 
característica de este proceso no se  al transporte.
podían  tratar  los  casos  de  uso 
“clásicos”  del  sistema,  como  se  Para  el  año  2008,  cerca  de  2000 
acostumbraba  en  el  desarrollo  de  empleados  de  tiempo  completo  y 
software,  sino  que  se  enfrentaban  medio  tiempo  se  encontraban  en 
a  un  sistema  en  tiempo  real  con  las  labores  del  departamento  para 
muchos aspectos integrados y cuya  proveer  los  servicios  de 
complejidad  iba  más  allá  de  la  administración  del  transporte  a  los 
implementación  de  las  interfaces  clientes  de  los    74  Centros  de 
de  usuario,  para  lo  cual  se  servicio  al  cliente  y  40  oficinas 
enfocaron en la identificación de los  administrativas  distribuidas  por  la 
“escenarios  operacionales  ciudad  y  para  esta  misma  fecha  el 
embebidos” los cuales básicamente  departamento  debía  administrar 
controlaban  el  hardware  del  más  de  75  millones  de  vehículos  y 
sistema,  siendo  estos  invocados  cerca  de  5.3  millones  de  licencias. 
por los casos de usos comunes que  Por  esto  con  el  fin  de  asegurar  los 
tenían básicamente la funcionalidad  niveles  de  servicios  de  calidad  así 
del sistema en cuanto a software. como  el  sostenimiento  financiero, 
el  Departamento  decidió 
Rediseño  del  sistema  de  implementar  el  modelamiento  de 
información  del  departamento  sus  procesos  como  parte  del 
de  automotores  de  Virginia,  esfuerzo para aplicar reingeniería y 
Estados Unidos definir  los  requisitos  del  sistema 
que  reemplazaría  el  actual  en  ese 
entonces, para lo cual se escogió el 
proceso  ICONIX  para  liderar  este  fusiona con las metodología SCRUM 
desarrollo [20].  para  el  desarrollo  diario  de  sus 
actividades,  hacen  de  esto  una 
poderosa  combinación  para  el 
desarrollo  de  proyectos 
CONCLUSION
tecnológicos  en  nuestro  panorama 
La  aplicabilidad  de  estos  procesos 
colombiano.
analizados  en  las  empresas 
colombianas,  vislumbra  a  ICONIX 
como  un  proceso  minimalista 
enfocado  rápidamente  de  los  casos  BIBLIOGRAFÍA
de  uso  a  la  construcción  de  las 
[1]   P.  Kroll  y  P.  Kruchten,  The  Rational 
partes  del  sistema,  siendo  una 
Unified  Process  Made  Easy:  A 
metodología  más  funcional  para  Practitioner’s Guide to the RUP, 1o ed. 
una Pyme en el entorno colombiano  Addison­Wesley Professional, 2003.

Vs  el  proceso  RUP,  el  cual  aunque  [2]   D.  Rosenberg  y  M.  Stephens,  Use 
es  un  proceso  bastante  completo  Case  Driven  Object  Modeling  with 
UML:  Theory  and  Practice.  Apress, 
es  demasiado  robusto,  complejo  y  2007.
costoso  para  ser  aplicados  a 
[3]   C.  S.  Stackpole,  A  User’s  Manual  to 
proyectos  de  IT  en  Pymes  the PMBOK Guide, 1o ed. Wiley, 2010.
colombianas  ambos  procesos  están  [4] «SysML.org  ­  Open  Source 
Specification  Project».  [Online]. 
basados  en  Lenguaje  de  Modelado 
Available:  http://www.sysml.org/. 
Unificado  (UML  por  sus  siglas  en  [Accessed: 26­Jun­2011].
ingles),  teniendo  en  cuenta  que 
[5]   K.  H.  Pries  y  J.  M.  Quigley,  Scrum 
RUP  dentro  de  su  proceso  utiliza  Project Management. CRC Press, 2010.
todos  los  diagramas  de  UML,  y  por 
[6]   J.  Palacio,  Flexibilidad  con  Scrum. 
otro lado ICONIX hace el modelado  Principios  de  diseño  e  implantación  de 
del  proyecto  más  simple  campus de Scrum. 2007.
reduciendo el uso de 14 diagramas 
[7]  J. Palacio y C. Ruata, Scrum Manager. 
que componen la notación UML a 4  Gestión de proyectos. 2010.
diagramas.  Finalmente  se  puede 
[8]   I.  Nonaka  y  H.  Takeuchi,  «The  New 
decir  que  ambos  procesos  realizan  Product  Development  Game», 
aportes  valiosos  los  cuales  deben  Hardvard  Bussines  Review  Hardvard 
College, págs. 137­146, Feb­1986.
ser  tenidos  en  cuenta  para  la 
apropiación  de  un  proceso  de  [9]   G.  Booch,  J.  Rumbaugh,  y  I. 
Jacobson,  El  proceso  unificado 
desarrollo  en  las  Pymes  desarrollo  software,  8o  ed.  Pearson 
Colombianas,  y  aún  más  si  se  Addison­Wesley, 2000.
View publication stats

[10]   B.  Boehm,  «A  spiral  model  of 

software  development  and 
enhancement»,  págs.  61­72,  May. 
1988.

[11]   K.  Beck,  Extreme  Programming 

Explained:  Embrace  Change,  US  ed. 
Addison­Wesley Professional, 1999.

[12]   B.  J.  J.  Voigt,  Dynamic  System 

Development  Method.  Suiza: 
Universidad de Zurich, 2004, pág. 16.

[13]   K.  Schwaber  y  M.  Beedle,  Agile 

Software Development with Scrum, 1o 
ed. Prentice Hall, 2001.

[14]  H. Kniberg, Scrum and XP from the 
Trenches. Lulu.com, 2007.

[15]   G.  Booch,  J.  Rumbaugh,  y  I. 

Jacobson,  The  Unified  Modeling 
Language User Guide, 1o ed. Addison­
Wesley Professional, 1998.

[16]   J.  D.  Prez–Jimnez,  A.  Durn,  y  B. 

Bernrdez,  «Fundamentos  para  un 
Entorno  de  Application 
LifecycleManagement  Dirigido  por 
Procesos»,  vol.  3,  no.  3,  págs.  41­48, 
2009.

[17]   I.  Becerra­Fernandez  y  R. 

Sabherwal,  Knowledge  Management: 
Systems  and  Processes.  M.E.  Sharpe, 
2010.

[18]   J.  Janák,  «Issue  Tracking 

Systems»,  Universidad  Masarykk, 
2009.

[19]   SINTEF,  ARKTRANS  Forprosjekt 

Felles, multimodal systemarkitektur for 
telematikk  i person­ og godstransport. 
pág. 2001 Septiembre 15.

[20]   Sparx  Systems,  «VIRGINIA 

DEPARTMENT  OF  MOTOR  VEHICLES.   
Systems  Redesign  with  Enterprise 
Architect.», pág. 6, May. 2011.