Dirección Estratégica Tic

FUNIBER 9
•
s1g a
........................................................................
DIRECCIÓN Y GESTIÓN
DE PROYECTOS TIC
,,
Indice
•• Presentación de la asignatura
Capítulo 1 •• Teoría del proyecto tecnológ ico
1.1. Introducción ... .. .. . .. . .. ... .. . ..... .. . ... .. .. . .. ... .. . .. . . ... .. ... ... .. ... .. ..... . .. . .. ... .... . ... ... . .. ..... 7
1.2. Proyectos : una visión teórica .. ..................... .... .. .................... .. .. ...... .. ...... ........ 9
<
1.2.1. Definición .. .. ..... ... ............ ..... ... ... ... .. .. ..... ..... .... ...... ... ... ... ... .... .......... ... 11
z
<
u
a 1.2.2. Tipología de proyectos .. .......... ...................... .. ........... .... ........ ......... .... . 15
"'o< 1.2.2.1. Taxonomía de proyectos ... .... ..... .. ............................. .. ........ .. 16
.,~
<
1.2.2.2. Proyectos a destacar .......................................................... ... 18
o:
<
>-
¡¡; 1.3. Teoría de proyectos ....... ..... ......... .. ... .... ..... .. .. .. ...... .. ... ... .. ..... .... .. .. ..... ...... .. .. .. . 21
~
~
z
::::i 1.4. Teoría del proyecto tecnológico .. ........ .. .............. ..................... .. .. ...... .. .......... .. 22
z
-o
ü
<
o
1.4.1. Visión de negocios y tecnológica ........................................................ .. 26
z
::>
LL
1.4.2. Dimensiones de gestión y de construcción 26
Capítulo 2 •• Gestión de proyectos
2.1. Introducción ..... .. ... ... ... ... .. .. . .. . .. ... .. ... .. .. . . .. .. .. .... . . .. ... ..... .. .. . .. . ... .. . .. ... ... ... ... .. ... 29
2.2. Noción de gestión de proyectos .. .. ................ ............ .. ............ .. ....................... 31
2.3 . La gestión de proyectos seg ún el PMBOK .. .. .. .. .. .. .... .... .. ... .. ......... ..... ... ..... .... .... 35
2.3. 1. Áreas de conocimiento de gestión de proyectos ... .. ..... .. ...................... ... 38
2.3.2. Procesos de gestión de proyectos .. .. .. .......... .............. ... ....... ................ . 61
2.3.3. Grupos de procesos de gestión .... .. .. .. .. .... .. ....... .. .... ......... ..................... 64
2.3.4. Relación entre grupos, áreas y procesos .. .. . .. .... .... .. .. .. .. .. .. ... .. .. .. .. .. .. .. .. . 65
DIRECCIÓN Y GESTIÓ N DE PROYECTOS T IC

FUNIBER
2.4. Modelos de Madurez de gestión de proyectos ...... .... ...... .. .... .. ........ ........ ........... 66
2.4.1. Capabtlity Maturity Mode/(CMM) .. .. .............. .. ....................................... 67
2.4.2. CMMI . .... .... ............ ..... .. . .... ............ .... ... .... . .. .... ..... ... ........... .... . ... .. .. . ... 72
2.4.2.1. Descripción general del modelo CMMI .. ..... ......................... .... 74
2.4.2.2. Descripción de los niveles del modelo CMMI .. .. .. .. .. . .. .. ... .. .. .. .. .. 75
2.4.2.3. Comparativa CMM versus CMMI ........ .. .......... .. .... .. .... .. . ...... .. .. 77
2.4.2.4. Evaluación . ... .. ... . .. .. . ... ... .. ... . .. .... . ... ... .. . .. . .. . ..... ... ... .. ... ... . ... .... 77
2.4.3. Modelos de madurez .................. ... ............ .. ... ... ... ........ ..... ............ ....... 78
2.4.3.1. Trillium model ............. ... .... ............... ... ... .......... ............... ..... 78
2.4.3.2. Project Management Assessment ..... ...... ... ............... ...... ........ 81
2.4.3.3. Project Management Maturity Model ...... .. ............................... 82
2.4.3.4. Innovatl'on Maturity Model ............. .. ...................................... 82
2.4.4. Implantación de la madurez ............... .... ............ .. ... .......... .... .... ........... 82
2.4.5. Modelos de Madurez en usos diversos ...... .. ............. .............. .. ...... ..... ... 84
<
z
<
~
2.5. Marcos de referencia de mejores prácticas de gestión .... ...... .................. ..... .. .. .. 85 5
"'o<
2.5.1. ITIL ................ .. .. .. ..... ... ......... .. .. .. ........................ ... ....... .. .. .. ....... .... .. .. 86 5
C)
2. 5. l. l. El Marco de Referencia de ITIL .. .. .. . .. .. .. .. . .. .. .. .. .. .. . .. .. .. .. .. .. .. .. .. 87

2.5 .1.2. Administración de Servicios (Service Management) .................. 89
2.5.1.3. Descripción de procesos de Soporte de Servicios .. .. .. ............... 92
2.5.1.4. Alcance de ITIL ........ .... .... ........... .... .. ................ .... ...... .. ....... . 99
2.5.1.5 . Implementación de ITIL ................................. ....................... 101
2.5.2. Sistema de Gestión de la Seguridad de la Información (SGSI) ................. 103
2.5.3. COBIT ..... .. ......... ... .......... ................... ...... .... ..... ..... ..... ...... .... .............. 108
2.5.3.1. Marco de referencia COBIT .............................................. .. .... 109
2.5.3.2. Modelo de madurez ............................... ......... .. ..................... 120
2.5.3.3. Alcances de COBIT ............... .. .. .............. ... ............................ 121
2.5.4. Benchmarkingcomo medio de encontrar prácticas .............. .. .............. ... 121
2.5.5. Marcos de Referencias versus CMMI .............. ..................... .. ................. 122
2.6. PRINCE2 ......... .............. ....... ...... ................ .. ... .... ...... ........ ........ ......... .......... .. 124
2.6.1. Descripción .... .... ... ........ ... .. ... ............. ...... ...... .. .... ............ .... ....... ........ 124
2.6.2. PRINCE2 versus PMBOK ......................................... .... ................. ......... 124
II DIR ECCIÓ N Y GESTIÓN DE PROYECTOS TI C

...
FUNIBER f
-------------------------------------
Capítulo 3 •• Ingeniería de software y gestión de proyectos
3.1. Análisis de proyectos por tipo de dimensión ........ ............ ... . ........ ........ ............. 133
3.1.1. Según dimensión del artefacto ............................................................. 134
3.1.2. Según dimensión de alcance ..... .. ......................................................... 136
3.1.3. Según dimensión del trabajo ............... ............................................... .. 137
3.1.4. Según dimensión de desarrollo ........................................ .... ........ ....... .. 138
3.1.4.1. Fases de desarrollo .............. ........................ ... ...... ................ 138
3.1.4.2. Modelos de desarrollo ............................. ... ..................... ...... 145
3.1.4.3. Modelo e-Project ............................................. .. .. ................. 160
3.1.5. Según dimensión organizacional .. . . .. .. . .. .. .. .. .. ... .. .. .... .. . .. ... .... .... .. .. .. .. ... . . 164
3.2. El problema del desarrollo informá.tico .. ............................. ......... .... .... ........ ..... 169
3.2.1. No si/ver bu/let.. aclarar el problema de la ingeniería de software.. ......... 169
<
z
< 3.2.2. Gestión de proyectos en informática .. .................... ............................... 173
~
e:
u
>: 3.2.2.1. Los problemas comunes en Informática ................................. 173
<
o
~ 3.2.3. Formas de evitar estos problemas ..... ... ................. ....... .. .. ............ .. ... .. . 183
::
"'
;: 3.2.4. Estados de una mala gestión de proyectos .... .. ............ .. ................ ........ 186
¡;;
e:
~
> 3.2.4.1. Modo ajustado ..... ....... .. ......... .. ... ........ ... ............ ........ ... ..... .. 186
z
::::l
z 3.2.4.2. Marcha mortal ......... .................................... ..... .................... 187
<>
ü
e
< 3.2.4.3. Fuera de control y escalada ....... .............. ..... .... ....... ...... ....... . 187
z
~
3.2.5. Razón de la gestión de proyectos ...... ..... .... .. ........ .. .. ...... .. .. .. ...... .. ...... .. 188
3.2.5.1. Actuación predictiva .............................................................. 188
3.2.5.2. Recuperación ... ..... .. .. ........ ....... ... .... ...... ...... ... .. .... .. .. ... . .. .... .. 189
Capítulo 4 •• Ejemplo de proyecto tecnológico:

implantación proyecto e-Business
4.1. Introducción ........................ ......................................... ... ........... .. ... .............. 193

4.2. Definir la estrategia ................... ......... .. ... ... ... .................... ........ ..................... 198
4.2.1. Definir la misión ... ........ ...................................... ... ............................. . 199
4.2.2. Establecer objetivos ...... ... ........................... ..... ............................. ...... . 200
4.2.3. Diseñar una estrategia ....................................................................... .. 202
4.2.4. Transformación de los procesos de negocio ........................................... 209
4.2.5. Factores críticos de éxito para una estrategia e-Business......... ............... 218
D IRECCIÓN Y GESTIÓN DE PROYECTOS TIC 111

4.3. Definir la aplicación e-Business .......................... .... ................ .. .................... .. .. 219
4.3.l. Identificar potenciales aplicaciones ........ .. .. .. .............................. ..... .. ..... 219
4.3.2. Definir arquitectura ........ ............... ........... ..... ...... ...... ...... ..... .... ............ 226
4.4. Desarrollo y despliegue .... ..... ... ..... ........ .. ...... ..... .. .... .. .......................... .. ......... 237
4.4.1. Desarrollo ....... .... ... ............... ....... ........... .. ......... .. ...... .. ...... ...... ... .... .... 237
4.4.2. Construir la solución e-Business ................................ .... ...... .. .... .. .......... 240
4.4.3. Factores críticos de éxito .. ........ .. .. .. .. ....... .... ................................ ...... .. . 243
4.5. Uso y evolución ... ....... ... .. ...................... .. ........... ..... ............... ....... ...... .. ..... .. .. 243
4.6. Ejemplo ... .. ....... .... ................... ............ ....... .. ....... ... .... ............ ..... ..... .... ..... ... . 245
4.6.l. La estrategia y la iniciativa e-Business ........ ... ............ .. .. .. .. .... ................ 245
4.6.2. El plan táctico ....................................................................... ... .... ... ... .. 246
4.6.3. Corolario .. .. ..... ...... ......... ... ............. .......... .... ....... .. ... ... ........ .... .. .. ... .... . 253
<
4.7. Soluciones e-Business ...... .... ........ ..... ........ ... .... ... .. .... ... .... ....... ..... ....... ... .. ... .... 253 z
<
....
;;;
w
z
<
Capít ulo 5 •• Herramientas y técn icas de gestión de proyectos o
::;
"'
5.1. Iniciación ..... ....... .. ........ ......... .. .... .. .. ...................................... ..... ...... ..... ...... .. 272 "'
e;
~
5.1.1. Motivaciones del proyecto ............. .. .. ...... .. .. ........ .. .... .... ...... ......... ........ 272 z
~
z
o
5.1.2. Selección del gestor del proyecto ............ ......... ... .. .............. .. ................ 273 ü
o<
z
5.1.3. Capacitación ... .. ..... .... .... .. .. .... .. ..... ...... ....... .... ... .. ... ... ... ...... ... .......... ..... 274 "'
..._
5.2. Plan ificación ......... ...... ... ... ... .... .. ... .... .. ..... .. .... ... ....... .... .. .. .. .. ........................... 274
5.2.1 . Estimación ..... .... .. ....... ... ... ............... .. ... ... .. .. ..... .... ... ............... ............ 275
5.2.2. Conformación del equipo .... ................... .......... ... ........... .. ............... .. .. .. 295
5.2.2.1. Selección de los miembros del equipo ......... ... .... .................... . 295
5.2.2.2. Estructura organizacional ...................................................... . 295
5.2.3 . Plan de proyecto ......... ... .... .. ... ..... ... ..... ......... ..... .... .... .......................... 301
5.2.4. Informe de alcance ........ ... ...... ... .......... ..... .... .. .... ... .. .... ....... ...... ... ..... ... 302
5.2.5 . Otras herramientas ... ..... .... ......... ........................ .. .. ...... ........ ....... .. .... .. 303
5.2.5.l. Diagrama de Ishikawa o Espina de Pescado ........ ..... ..... ......... . 303
5.2.5.2. Qua/ity Function Deployment(QFD) ............ ..... ................ ...... 307
5.3. Control y seguimiento .......... ............... ..... ..... ......... ......... .... .... ... .. .............. ... .. 313
5.3.1. Aseguramiento de la calidad .. .. ... .. ....... .......... ......... ...... ........ .... .. .. .. .. .. .. 313
5.3.2. Tiempo y coste .... .. ......... .. ...... ... .............. ............. ........ ... .............. .... .. 315
IV DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC

5.3.3. Desempeño y evaluación .... .. ............................................................... 319
5.3.4. Recursos humanos .. ......... ........................... .................... .. .................. 322
5.4. Cierre .. ... . .... .. . ... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .... ... .. .. . ... .. .. . . .. . ... .. .. ... .. .. .... . ... .. .. .. .. .. .. . ... .. 324
5.4.1. Cierre administrativo ............................. .............................................. 325
5.4.2. Cierre de contratos .... ... ...... ..... .... ... .... .... .............. .. ... ... ... .. ........ ...... .. .. 325
5.5. Cuadro resumen de las etapas de un proyecto 326
•• Bibliografía
<
~
u
§
:t
<
o
"'
"'"'
::
::"'
v;
~
::z
::>
z
•!:?
u
<
o
5
LL
D IRECCIÓN Y GESTION DE PROYECTOS TIC V

Fu N 1BE R f ~ -------¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡m;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
P¡¡¡
RE¡S¡¡
¡EN¡¡¡
TA¡¡CiiiilllÓ·N·D·E.LA·A·S·JG
....
" --i..-?.A
,
PRESENTACION
E A AS I G Í\J ATU RA
<
Justificación
z
<
u
§
:r
<
No es posible en la actualidad concebir una acción humana sin un mínimo de previsión y
o
o:
w planificación. Hacerlo es cae r en el absurdo de actuar en incertidumbre. Si la acción
"'<
o: humana involucra el uso de recurso s humanos y no-humanos desplegados en el t iempo ,
<
un proyecto, la previsión y la planificación son imprescindibles. En ingeniería es
~>
imperdonable, en los negocios impensable.
:!3
z
·O
ü
<
o Conocer cómo un proyecto se lleva adelante requ iere varios ámbitos de dominio, lo cual
z
.._::> hace el estudio de los proyectos como objeto de estudio, una tarea compleja , pero no
,,.
""' inalcanzable .
En el ámbito de la Informática, de los Sistema de Información o de los Sistem as de

Ingeniería de Software o Telemáticos, se suele recurrir mucho a la poco adecuada y
poco profesional expresión de que este tipo de proyectos es difícil de planif icar y
organizar como un proyecto . Esto es muy frecuente en el mundo y oficio de la
Informática en general. Los argumentos son razonables. Motivos como la incerteza de
las tareas, la complejidad de los requerimientos, la volatilidad del software, etc. son
obvios y podrían justificar el evitar un pensamiento proyectual previo al inicio de un
proyecto cualquiera. Pero si se acepta esta premisa , sería asumir que otros campos, con
sus propios proyectos no podría hacerlos. La economía ha mostrado que lo intang ible es
medible, la organización empresarial ha mostrado que las personas y la administraci ón
se puede proyectar, la arquitectura y la construcción han mostrado que los sueños se
pueden concretar a través de proyectos, y así se puede ir re visando diversas
profesiones y campos de conocimiento y se aprecia que si hay proyectos, que sí se
pueden prever y proyectar y, más aún proyectar .
DIRECCIÓN Y GEST!ON DE PROYECTOS T IC 1

FUNIBERÍ~
P RESEN TA CI ÓN DE LA A SI GNATU RA
La distinción en los tiempos modernos con relación a estos proyectos tecnológicos es

que ya no son compe ndios de esfuerzos orientados a producir artefactos , sino que
AD EMÁS , a proveer soluciones de negocio. Por este motivo , un proyecto tecnológico
requiere comp rend er su dimensión de negocios y su dimensión de tecnología.
En este sentido se deben gestionar los proyectos tecnológicos con toda la formalidad de
un negocio. La s estadísticas demuestran que gran ca ntid ad de lo s proyectos de
tecnológicos, especialmente del ámbito TIC , fracasan, respaldada esta afirmación en el
hecho de que se ha dem ostrado que solamente ce rca del 35 % de los pro y ectos de
desarrollo y construcción de alguna tecnología TIC tienen éxito y se están asumiendo
pérdidas millonarias en euros/ dólares. El problema v iene causas tan frecuentes como
conocidas: escasa participación de los usuarios, falta de apoyo directivo , requer imientos
y especificaciones incompletas, crono.gramas irreales, exp ectat ivas no realistas , pobre
seguimiento a proyectos , incompetencia en el dominio y comprensión y uso de las
tecnologías , falta de un dueño del proyecto , objetivos y visión poco claros , trabajo de
los equipos enfocado en apagar incendios o atender urgencias, entre otros. En todos los
casos , se aprecia que estos problemas se resuelven con el uso de prácticas de gestión z<
:
<
o
proyectos debe integrarse co n la o ser parte de la gestión del desarrol lo de tecnologías . ::;
"'
Descripción de la asignatura
En la asignatura se hace una completa una exposición teórica y aplic ada sobre el amplio
campo de proyectos. Se revisa de manera íntegra la gestión de proye ctos y su
aplicación en el mundo de los proyectos tecnológicos. La ap li cación del conoc imiento
introducido en la asig n atura se ilu stra con un proyect o e-Business .
Los capítulos son:
• Capítulo 1. Teoría del proyecto tecnológico. Ex posición de la teoría de pro yectos a

partir de sus fundamentos hasta concluir con un ejemplo de proyecto tecnológico e-
Business .
• Capítulo 2. Gestión de Proyectos. Revisión del campo de la gestión de proy ectos ,

desde un anális is del c oncepto hasta su actual despliegue según el estándar
PMBOK . Se completa re v is ando Modelos de Madurez, M arcos d e refe ren ci a de
buenas prácticas de Gestión y el enfoque PRINCE2.
• Capítulo 3. Ingeniería de Software y Gestión de Proyectos. Integración de

elementos de Ingeniería de Software con componentes de la Gestión de Proyectos
com o antecedente de un proyecto tecnológico .
2 D IRECCIÓ N Y GESTIÓN DE PROYECTOS TIC

__
PR ESENTACIÓN DE LA A SIGN AT URA
FUNIBERff .......................................
• Capítulo 4 . Ejemplo de proyec to tecnológico : implantació n del proyecto e-Business.

lustración de la gestión de un proy ecto tecnológico a tra vés de una metodología de
implantación de un proyecto e-Business en su dimensión de negoc ios y en su
dimensión de tecnología.
• Capítulo 5. Herramientas y técnicas de gestión de proyectos. Rev isión

pormenoriz ada de he rrami entas y técnicas de gestión de proyectos para el caso del
proyecto tecnológico.
Objetivos
Objetivo General
Dominar las herramientas y técnicas de gestión de proyectos en proyectos de

tecnología en su dimensión tecnológ ica y en su dimensión de negocios.
Objetivos Espe cíficos

<
z
<
u
§ • Analizar la teoría del proyecto tecnológico.
:i:
o<
~ • Describir el instrumental conceptual y aplicado de la gestión de proyectos .
• Distinguir los diversos aspectos de un proyecto tecnológ ico informático y el

instrumental que requiere para su dimens ión tecn ológica y su dimensión de
negocios.
• Deli near cómo se organiza la implantació n de un tipo de proyecto tecno lógico en su

dimensión tecnológica y de negocios.
• Identificar las herramientas y técnicas de gestión de proyectos idóneas a un

proyecto tecnológico.
DIRECCIÓN Y GESTIÓN DE PROYECTOS TI C 3

FUNIBERf~
TE ORÍA DEL PROYECTO TECNOLÓGICO
------------------------------------
,
Ca 1
1
0 1
,
TEORIA DEL
, PROYECTO
<
z
<
~
TECNOLOGICO
5:¡:
<
o
5
=
:!:
"'~
¡¡:;
5
::
z
::i
z
·O
V
<
Q
z
"'
u..
- Comprender la noción de proyecto.
- Conocer y comprender las dimensiones de un proyecto informático
- Reconocer la importancia de una Teoría de Proyectos.
- Comprender la complejidad de un proyecto e-Business desde una perspectiva teórica .
Los proyectos no son nuevos. Las pirámides egipc ias , el Partenón griego , la gran
muralla china, son ejemplos de la empresa humana ejecutadas en la forma de
proyectos. Aún más, la Creación del Mundo es un proyecto ejecutado en 6 días, medido
en días, con recursos supuestamente ilimitados y con un resultado dejado en manos y
juicio de los usuarios ... Adán y Eva .
DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC 7

TEORÍA DEL PROYECTO TECNOLÓGICO
FUNIBERff
La lista ante rior puede aumenta r se co n cosas más cotidianas. Te r mina r este texto,
terminar el mes dentro de cie rtos gastos, un estudio de doctorado . Por supuesto están
los llamados formalmente proyectos d e ingeniería, proyectos de arte, proyectos
educativos, y m uchos otros tipos, de entre los cuales los proyectos e-Business son de
interés debido a que pe rmiten hacer un análisis de negocios y tecnológ ico para un
proyecto tecnológico. Se quiere hacer ver que concept ualmente un proyecto e-Business
permite distinguir los dos elementos centra les a cua lqu ier proyecto tecno lógico: la
dimensión de negocio y la dimensión tecnológica.
Nota:
El término e-Business fue popularizado a partir de un eslogan lanzado por IBM como parte de una de sus
estrategias. El día 7 de octubre de 1997, Louis Gerstner, CEO de IBM decía que IBM buscaba posicionar como
empresa líder y promover una nueva imagen.
e-Business es lo que ocurre cuando una empresa conecta sus sistemas informáticos a sus clientes, empleados,
distribuidores y proveedores, a través de intranets, extranets o Internet.
IBM tomo la propiedad del término en minúscula (trademark) "e," pero el tiempo ha mostrado
<
que una definición de e-Business no debería depender de un signo singular o el particular z
<
mensaje de mercadeo promovido por una compañía . ~
"'>:
Sin embargo, este concepto tan sencillo se convierte rápidamente en algo muy eficaz. En el momento en que <
o
todos los clientes, empleados, proveedores y distribuidores están conectados a los sistemas de la empresa y :::"'
obtienen la información que necesitan, está claro que e-Business conlleva una transformación de la empresa.
Por este motivo, lo que se buscaba, más allá de una definición de e-Business potencialmente supeditada a una ~
w
estrategia y por ello notoriamente susceptible a interpretación retrospectiva, era algo que no debería ser un ::z
sueño que el 95% de las compañía no pudiesen conseguir. La cuestión no era si usar la "e" o no usar la " e" ::>
z
como un esquema de clasificación. Se buscaba poder llegar a una definición que debería ser tan válida 10 años -e
ü
antes de Internet y 10 años de Internet cuando ya sea obsoleta. Esto implica que la "e" debe ser aplicable a <
o
z
cualquier empresa, independiente de su escala, tal que pueda cualificar como un e-Business. ;:,
u.
Fuente principal: ALTER, STEVEN. (2001). Does the trend Toward e-Business Cal/ far Changes in the Fundamental
Concepts oflnformation Systems? A Debate. Communications of the AIS, 5(10). April. http /ca;"· a1snet.ora
Un proyecto e-Business puede definirse como el esfuerzo de examinar una iniciativa o solución e-Business y
anticipar su potencial impacto en las personas, los procesos de negocios, la organización y las inversiones en
Tecnologías de la Información (TI). El resultado de un proyecto e-Business es una aplicación, o conjunto de
aplicaciones, e-Business, esencialmente tecnológica, cuya existencia se justifica solamente en la medida de
dar soporte a la iniciativa e-Business dentro del marco o escenario de negocios o mercado al cual una
organización aspira ( ).
Iniciativa Aplicación
e-Business
PROYECTO
E-BUSINESS
l
--- e-Business
Figura 1.1: Proyecto e-Business.
8 DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC

..... TEORÍA DEL PROYECTO TECNO LÓG ICO
~~~~-f ____________illiilil¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡==:~;;¡;¡¡¡;¡;¡~
Para comprender esta definición , es necesario presentar varios conceptos generales,

cuya claridad conceptual permitirá comp render las diferentes dimensiones de un
proyecto e-Business.
Por tal moti vo, pr im ero se re visa el concepto de proyecto. Luego se revisan los
diferentes tipos de proyecto info rmáticos según va riados crite r io s. A continuación, y
para proveer una base de discusión más amplia , se explica el concepto de Teo ría de
Proyectos destacand o una de ellas. De esta manera , se expone finalmente una Teoría
del Proyecto e-Business a partir de la noción de proyecto presentada inicialmente. El
detalle de tal planteamiento se ve cimentado en una presentación extensa sob re los
proyectos informát icos.
<
Para llegar a entender lo que es un proyecto cualquiera, resulta conveniente empezar
z
";;:u conociendo lo que se entiende por un proyecto , por tratarse de un término que, pese a
~ ser de uso común , puede tomar significados diferentes y no siempre se emplea en el
"oo:
..
w mismo sentido o con la precisión conveniente.
";;:<
;¡;
::: Proyecto, desde una perspectiva general y teórica, se puede definir como la acción intencionada de hombres
::z
:::>
z
y/o mujeres hacia la consecución de un resultado o, el medio o la acción organizacional mediante la cual una
o organización, empresa o negocio, busca respuesta a un problema o conflicto. Tal acción da lugar a una
ij
"
e
z solución instrumental, en la forma de un producto o servicio.
:::.
u.
Otra definición de proyecto puede ser " .. . un conjunto planificado de acciones tendientes a resolver
exitosamente ·mediante una ca ntidad de recursos humanos y materiales, un presupuesto y un tiempo para su
realización- una situación problemática o una demanda planteada". Completar con el éxito del proyecto
significa cumplir con los objetivos, dentro de las especificaciones técnicas, de costo y de plazo de terminación.
Un proyecto siempre da lugar a una solución. Esta solución tiene varias particularidades:
• Es habitualmente injertada en la misma organización que la requirió , por lo cual la

solución ha de ser coherente con la organización , tanto en el ámbito tecno lógico
como en el hu mano.
• Surge instrum enta lmente por un acuerdo entre proyectistas y clientes en razón de
tiempo , costo , ganas y satisfacción en resolver un confl icto.
• En sí mi sma req uiere de un a empatía y un equilibrio entre lo que se pide, desea o

anhela, y lo que se puede con los medios humanos y tecnológicos .
DIRECCIÓN Y GESTION DE PROYECTOS TIC 9

TEO RÍA DEL PROYEC-0 TECNOLÓ GICO
Proyecto, desde un pu nto de v ist a m ás co n cret o, se concibe como una o pera ción de
enve rgadura y complej idad notab les , singular, con unas fechas definidas de inicio y
final ización. Es un t rabajo no repetitivo, qu e ha de planificarse y realizarse según unas
espec ificaciones técni c as det erm inadas, con un presup u esto preestablecido y una
organización temporal con la pa rt icipación de varios departamentos de la empresa que
se desmantela cuando termina el proyecto, y que incluye, ta l vez, la colabo ració n de
terceros.
Este concepto emerge de obse rvar que las tareas humanas se organizan bajo ciertas
condiciones, cuyo manejo y aprovecha m ie nto pre-figu ran las cualidades que afectan
todo proyecto.
• Persecución d e uno o varios objetivos . Las actividades aisladas no constit uyen por
sí solas , un proyecto. Para que exista un proyecto, debe existir una coordinación de
actos orientados a la consecución de uno o v arios objetivos , integrados entre sí y
estructurados, tant o de ín do le técnica como económica. En gene ral, el objetivo
general de un proyecto es satisfacer un conjunto de requisitos a un coste dado en z<
<
u
las condiciones más eficientes. a:
::¡:
<
o
• Actividades planificadas, ejecutadas y supervisadas . La coordinación de actividades ~
<
es condición sine-qua-non pa ra que a las mismas , en su conjunto , se les pueda a:
<
calificar de proyecto. De hecho, un proyecto exige que exista vinculación entre las "'"'
"'~
activ idades , pues t o q u e persig u en un objet ivo común. Esa vincu l ación debe z
::>
z
plasmarse en forma de planificación (técnica, t emporal y económ ica) cuya correcta ·O
ü
<
o
ejecución supervisada es clave para el éxito o fracaso del proyecto. z
::>
u.
Q
• Disponibilid ad limitada de recursos . El proceso proyectual implica la búsqueda de la
eficiencia en el uso de los recursos para obtener el resultado perseguido. Si los
recursos son ilimitados, desapa rece el concepto de eficiencia y con él la naturaleza
proyectual de las actividades.
• Limitación de tiempo . Un proyecto debe estar acotado en términos del principio y el

fin mismo. El fina l de un proyecto se alcanza cuando se cumplen los objetivos pre-
fijados , o cuando se hace evidente que dichos objetivos no pueden alcanzarse
(fracaso del proyecto). Po r otro lado , aunque el proyecto tenga que estar acotado
en el tiempo, no sucede lo mismo con sus resultados , que pueden perdurar con
carácter indefinido (por ejemplo , una catedral) .
Así, se puede llegar a decir que los proyectos se ca racterizan en general por:
• Tener objetivos específicos;
• Deben completarse dentro de un periodo determinado;
10 DIRECCIÓN Y GESTJON DE PROYECTOS TIC

TEORÍA DEL PROYECTO TE CNOLÓGICO
• Tene r inicios y té rminos bien definidos;
• Deben completa rse dentro de las restricciones de un presupuesto;
• Ser ejecutados po r un equipo; y,
• Ser únicos.
1.2.1 DEFINICIÓN
Las acepciones previas pueden considerarse extremas dentro de un amplio abanico de

definiciones de 'proyecto'. Por tanto, la pregunta es: ¿qué es un proy ecto?
Esta pregunta ha llevado a diversas definiciones, o más bien , formas en que se entiende
un proyecto, todas ellas válidas , cuyo conocimiento perm ite mostrar visiones sesgadas
de un mismo fenómeno.
"z
"o:~ • Es un esfuerzo conjunto de muchas personas - hombres y mujeres- que buscan
...:1: el máximo beneficio en conseguir una solución razonable a un problema que se
<
o
.,::¡ espera tenga la solución ideal.
~
"'<
~
• El proyecto es una operación que se expresa como una experiencia práctica
:::"'> cooperativa y colaborativa en la cual:
z
:::>
z se usan conceptos abst ractos (por estar en dominios de conoc1m1ento
~
u
<
transversales) junto a conceptos técnicos (por estar en dominios aplicados
o
z
:::> concretos) que se manifiestan en documentos (por ser medio de expresión
u..
? natural y persistente de las pe rsonas).
• Es el conjunto de acciones destinadas a reso lver o vulnerar un problema ya

identificado, priorizado y explicado en el mome nto de investigación de
problemas críticos.
• Es un conjunto autónomo de inversiones, pol ít icas y medidas instituciona les y

de otra índole , diseñadas para lograr un objeti v o específico (o serie de
objetivos) . Se puede definir como un modelo para las asignaciones de recursos ,
que tienen un tiempo de ejecución y se logran resultados med ibles. También se
identifica, como la menor unidad de actividades , que puede ser plan ificada y
ejecutada aisladamente de la planificación de operación y sostenimiento de los
servicios de Salud. Constituye la unidad operativa más pequeña que desde el
punto de vista lógico , se presta para la planificación , el financiamiento y la
ejecución como unidad independiente dentro de un plan o programa de
desarrollo local.
• Es un proceso para obtener recursos, destinado a conv ertir una idea surgida de
los planes nacionales, de las necesidades lo c ales e instituciona les y de las
situaciones de emergencia, con el fin de fre n a r el deterioro o cont i nuar el
desarrollo de los servicios sociales.

FUNIBERf~~
TEOR ÍA DEL PROYECTO TECNOLÓG ICO
• Es un conjunto específico de actividades en las que se invierten escasos

recursos con la esperanza de obtener beneficios.
• Es el conjunto de acciones o actividades que se realiza a partir de una situación

actual para obtener una situación futu ra o esperada.
• Es la unidad operativa más pequeña que puede ser ejecutada en forma

independiente o autónoma, constituida por un conjunto de actividades o tareas
encadenadas .en un orden lógico, destinadas a cumplir un fin específico a incidir
en la magnitud de una o más v ariables , determinada por la realidad a la que se
orienta.
• Es una información estructurada con valor agregado que permite la articulación

de recursos humanos de diferentes estru cturas de la organización y de
diferentes disciplinas y funciones.
• Es una empresa planificada con un conjunto de actividades para alcanzar un

objetivo , con un presupuesto y un tiempo previ amente determinado, que como
la mayoría de los procesos humanos tiene carácter cíclico, y la clave de su
dinámica es la transformación de la rea lidad y el avanzar hacia un estadio
superior del desarrollo.
• Es un proceso cuyo objetivo es transformar una idea en un producto term inado,

constituido por bienes o servicios que serán los medios para producir otros <
o:
bienes o servicios, y consta de 3 características fundamentales: <
Es un proceso finito , es deci r, que se cuenta con un per íodo de tiempo

determinado para alcanzar el objetivo.
Cuenta con un presupuesto preestablecido para alcanzar el objetivo.
Es un proceso único (no repetitivo) en que las actividades van ligadas por
requerimientos de secuencias y por tanto en cada etapa las acti vi dades son
diferentes.
• Es un conjunto no vacío de tareas estructuradas, que se desarrollan en un plazo

de tiempo finito y acotado , con objetivos bien definidos aco rdes con su misión
y que se alcanzan con la integración de las soluciones parciales de las tareas, a
parti r de un diseño con enfoque sistémico y en función de la visión, en el que se
combinan los recursos con criterios de optimización , de acuerdo con sus
requerimientos y restricciones, tomando en cuenta y evaluando los riesgos.
• Es un proceso único, consistente en un conjunto de actividades controladas,

con fecha de inicio y finalización, llevadas a cabo para lograr un objetivo
conforme con requisitos específicos, inclu idas las lim itaciones de tiempo , costo
y recursos.
• El proyecto es una operación de ingeniería que invo lucra pasar de un sistema
deseado a un sistema a ofrecer (ver ), lo cual implica:

T EORÍA DEL PROYECTO TECNO LÓGICO
ir de una idea inmaterial y difusa pro veniente de un problema o necesidad a

un orden amiento t écnico formal y estructurado de tareas que regulan las
acciones de hombres y mujeres para conseguir objetivos predeterminados.
Estas definiciones incluyen varios at ributos (ver ) pero es mejor agrupar estas
definiciones en dos grupos:
• Proyecto como producción de artefactos; y,
• Proyecto de acción.
Presupuesto
Acciones y
Objetivo
actividades
<
z
:
<(
o
~
<(
"'
<(
>--
¡;;
"'
w
?;
z
Espacio Problemas
::>
z
-O
ü
< Tiempo
o
z
"
lL
Figura 1.2: Atributos principales asociados a la definición de proyecto.
Proyecto
Situación Situación
Problema
actual esperada
Figura 1.3: Generalización del concepto de Proyecto.
DIRECCIÓN Y GESTIÓ N DE PROYECTOS TIC 13

FUNIBER f~
T EORÍA DEL PROYECTO TECNO LÓG ICO
a) Producción de artefactos.
Un proyecto se comprende habitualmente como un medio para obtener un

artefacto, un r esultado material concreto. De entre las múl t ip les definiciones
que plantea el proyecto en estos términos, es posible distingui r dos acepciones ,
ambas simila r es, pe ro apuntando a d istintas fina lidades según quien tiene la
misión de di rigi r les. Así se puede hablar de:
Proyecto como program a a seguir . En este caso el 'proyecto' es equivalente

a cumplir plazos y fechas , y entrega r documentación.
Proyecto (según el Diccionario de la Lengua Española de la Real

Academia Española):
"Planta y disposición que se fo rma pa ra un tratado, o pa ra la ejecución

de una cosa de importancia, anotando y extendiendo todas las
circunstancias principa les que deben concu rrir para su logro".
Projecte , según el Diccionari de la Llengua Catalana del lntitut d'Estudis

Catalans , es:
<
z
<
"A/16 q ue hom pensa portar a acompliment; pla propossat pera rea/itzar- u
"'
ho; estudi detallat d'una cosa rea/itzar".
Proj ect (según el Diccionario Oxford):

:::
"'<
" Hacer planes para ('Make plans far')".
Proyecto como consecución de objetivos . En este caso el 'proyecto' es

equivalente a alcanzar objetivos.
Para Ribera :
"Un proyecto es una secuencia unica de act ividades complejas e

interconectadas que tienen un objetivo o propósito q u e debe ser
alcanzado en un plazo estab lecido , den t ro de un presup u esto y de
acuerdo con unas especificaciones".
Según el Project M anagement lnstitute :
"Un proyecto es un esfuerzo temporario re alizado pa ra crear un

producto , servicio o resultado único." ('A Project is a temporary
endeavor undertaken to create a unique product, service, ar result' .)
Seg ún Juriso n :
"Ensamblaje de recursos para solucionar un problema de un determinado

tipo ('Assemb/age of resou rces to so/ve a one-of-a-kind problem') ".
b ) Proyecto de ac ción .
En un proyecto de acción el fin no es producir un artefacto, sino encontrarlo y

definirlo. En este caso, existe una componen t e de ap rendizaje para , 'aprender' a
resolver problemas.
14 DIRECCIÓN Y GESTIÓN DE PROYECTOS TI C

FUNIBER~ .................................................. --
TEORÍA DEL PROYECTO TECNOLÓG ICO
Proyecto , para Blasco , es :
" La operación de ingeniería que nos lleva a conseguir un objetivo material

predeterminado por modificación de la realidad exterior mediante unas
acciones humanas que han sido seleccionadas y ordenadas con anticipación
de acuerdo con unos criterios".
Para Dahlbom y Mathiassen , proyecto es una acción donde se:
se interviene, debido al cambio en el entorno que se produce por la

propia existencia del proyecto como por el resultado que se genera y se
pone en el medio;
se evoluciona , debido a buscar la solución de un problema que no es fijo

ni estable , sino que se va dando conforme el proyecto está en
ejecución; y,
se construye, por desarrollar una solución técnica que es la respuesta a

un problema.
<
z
<
u
;;
z 1.2.2 T IPO LOGÍA DE PROYECTOS
<
g
"'
:: Las visiones previas muestran que un proyecto involucra dos proyectos de enunciado
"'....<
;¡; teórico: proyecto para construcción de artefactos y proyecto de acción , cada uno de los
"'> cuales, según su relevancia y su grado integración mutuo, han llevado a que clasificar
z
::>
z
·O
un proyecto no sea una labor sencilla. Más bien es una labor comp leja , pue s su va riedad
~
o y diversidad es alta. Sin embargo, es posible sugerir una tipología general dependiendo
z
...::. de algunos criterios .
Q
La tipología general aquí presentada utiliza criterios de distinción :
• Por objeto , o por el objeto que esta tratando el proyecto ;
• Por actividad , o dependiendo de alguna fase en el ciclo de vida de un producto ;
• Por rol del usuario , por el contexto en el cual se desarrolla el proyecto ;
• Por campo de ingeniería, o por la disciplina, ciencia y /o técnica que predomina en el

proyecto;
• Por naturaleza del resultado , o por el tipo de producto a obtener .

T EORÍA DEL PROYECTO TECNOLÓGICO
FUNIBER
1.2.2.1 Taxonomía de proyectos
Debe aclara rse que estos criterios ni son todos ni son determinantes.
a) Por objeto .
Proyecto clásico. Se aborda la realización de una serie de documentos que

define la ob ra o t r abajo a realizar para su ejecución en un futuro. El alcance
comp rende la identificación, evaluación , organización y va loración de las
acti vidades que faltan pa r a conseguir o cu lminar el resultado perseguido,
pero en su alcance no está comprometida la realización de las mismas. El
resultado es una memoria, unos planos , un pliego de condiciones y un
presupuesto y, a lo sumo, un prototipo o maqueta del objeto en cuestión.
Proyecto de investigación . Su objetivo es aportar en su conclusión un

conjunto de conocimientos nuevos en una disciplina y materia concreta , a
menudo desconocida al comienzo de los trabajos. Su fin es que otros se
vean beneficiados, sea en entornos industri ales o académicos. El resultado
es una memoria de in ves tigación donde, aparte del planteamiento del <
z
<
problema a resol ve r y la descripción del estado del arte, se r eseñan los u
§
z:
trabajos real izados, los re s u ltados de los mismos y las conclusiones <
o
pertinentes, junto con las líneas de investigación futuras propuestas en esa ::¡
:::
disciplina concreta . <
"'<>-
;;;
b) Por actividad. "'
~
:-:
z
::>
Estudios y análisis . En ocasiones el alcance de un trabajo concreto se limita o
z
u
a analizar o estudiar la información disponible acerca de los aspectos <
o
técnicos , económicos, ambientales y sociales de un determinado problema. ...5
En este caso el proyecto rec ibe el nombre de estudio (co mpren sión o
conoc imiento del problema o análisis (examen del problema para
co mprender los principios del mismo).
Estudios de viabilidad . Los estudios de viabil idad deben proporcionar la

base- técni ca, económica y comercial para la decis ión de invert ir en un
proyecto industri al. En estos estudios se deben definir y analizar l os
elementos críticos relacionados con la fabr icac ión de un producto dado ,
junto co n otros enfoques posibles a tal producción. Un estudio de este t ipo
debe dar por resultado un proyecto con capacidad de producción definida en
un emplazamiento seleccionado, utili zando una o v ar ias tecnologías
determinadas en relación con materiales e insumos específicos con costes
de inversión y produ cció n identificados, e ing resos por concepto de ventas
que produzcan un rendimiento determinado respect o de la inve rsión .
c) Por rol del usuario .
Para entender este rol hay que identificar si el proyecto es interno o externo y si
el cliente es interno o externo . Esta relación se basa en distinguir entre quien
desarrolla el proyecto y quien lo pide (el cliente) .
16 DIRECC I ÓN Y GESTIÓN DE PROYECTOS TIC

FUNIBER$~
T EORÍA DEL PROYECTO TECNOLÓGICO
_ _ _ _ _ _ _ _ _ _ _ _ _ _. - ¡_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _
Proyecto externo . Los proyectos externos a la organización son aquellos en

los que el cliente es ajeno a la empresa que hace los trabajos. Se rige
fundamentalmente por criterios de mercado , incluyendo competiti vidad y
eficacia. Quien desarrolla el proyecto actúa como consultora.
Proyecto interno. Los pro yect os internos a la organización , son aquellos en

los que el cliente es de la misma empresa que desarrolla los trabajos. Suelen
se r proyectos de mejora intern o, intra-departamentales, etc.
d) Por campo de ingeniería.
Por campo de ingeniería, se t ienen proyectos diversos:
Productos naturales . Ingeniería agronómica , oceanográfica , forestal y

minera. La obtención de productos naturales requ iere unos proyectos mu y
en contacto con el medio que se va a tratar, con mucho trabajo de campo y
la necesidad de un gran soporte documenta l, pero con escasa interrelación
entre los equipos y máquinas necesarios, lo que evita la necesidad de una
definición minuciosa de los mismos que condicione las fases posteriores del
trabajo.
Infraestructuras y edificaciones . Ingeniería c ivil , construcc ión. La

construcción de infraestructuras y edificaciones de todo tipo se apoya en
disciplinas f unda mental es como topografía , geotecn ia y resistencia de
materiales, y exige proyect os detallados con profusión de cálculos y planos ,
pero cuya ejecución es prácticamente independiente, en el tiempo , de los
documentos que configuran el proyecto .
Productos manufacturados . Ingeniería industrial, mecanica , electrónica ,

automática , química, aeronáutica , naval. Los productos manufacturados
exigen unos proyectos muy complejos , con muchas disciplinas implicadas y
numerosos equipos, máquinas y aparatos interconectados, que exigen gran
atención y abundantes especificaciones.
Servicios /sistemas ligados a ingeniería eléctrica, energía, telecomunicación ,

informática . En este caso hablamos de produ c tos cuya esencia es
intangible , por su natu r aleza inmaterial que d ificulta su manipu l ac ión
co rpórea.
e) Por naturaleza del resultado .
Proyecto de ingeniería . En este caso estamos ante un proyecto de acc1on ,

donde esencialmente se persigue resolver un conflicto definiendo cual sería
el potencial sistema solución.
Proyecto industrial. A diferencia de los proyectos clásicos , los proyectos

industriales comienzan y terminan en sí mismos , dando luga r a un producto
o servicio terminado (sin que ello sea obstácu lo para que otros proyectos
comiéncen posteriormente desde los resu ltados del primero ). Inv oluc ra una
planificación en la ejecución de actividades orientadas a un fin concreto (el
bien o servicio) por lo que una vez finalizado el mismo , la replicación de los
resultados no constituiría un proyecto en sí m ismo.

FUNIBERf;
Este tipo de proyectos , por su relevancia y genera li dad se detallan a continuación.
1.2.2.2 Proyectos a destacar
a.- Proyecto de ingeniería
Por su relevancia , en este apartado se profundiza en los proyectos de ingeniería. Los

Proyectos de Ingeniería tienen una serie de características comunes que se citan a
continuación:
• Complejidad . Una serie de factores, como el trabajo requerido para su realización, el

tamaño de l a inversión, todo el tiempo necesario para lle va rlo a cabo más l as
importantes responsabilidades que van asociadas a ello hacen complejo un
proyecto de ingeniería. Por su enorme complejidad es preferib le dividirlo en partes
mucho más pequeñas que pueden ser estudiadas más profundamente.
<
• lntegrabilidad . La mayoría de los proyectos que se realizan en la actualidad se z
..,<
caracterizan por la necesidad de cubrir todas las etapas desde el principio ~
:E
<
o
(proyectos completos o integrales), cuando sólo existe una idea de algo que o:
~
queremos materializar hasta el final , cuando se ha transformado en una realidad. "'
No obstante, a veces se tiene la imp resión que se suprimen algunas etapas

~
intermedias. Esto no es del todo cierto, lo que ocurre simplemente es que se ~
z
::>
utilizan otras vías, recurriendo a informaciones ya existentes o simpli fica ciones. z
o
ü
<
• Multidisciplinariedad. Los proyectos que a veces se llevan a cabo son de tal "z
,¡:
envergadura que se necesita un amplio equipo de profesiona les cada uno de ellos ~
expertos en una disciplina, co n amplios conocimientos técn icos. Por ello , u na

tercera característica para proyectos de ingeniería complejos e integrales es la
disponibilidad de conocimientos multidisciplinares .
b.- Proyecto industrial
Los proyectos industriales se diferencian de lo s otros en la menor importancia que se

atrib uye a las características del terreno donde se local iza desde el punto de vista
técnico , además se exige una definición precisa de todos los equ ipos y máquinas que
componen el sistema de producción. En este tipo de proyectos la fase documental se
puede desarrollar independientemente de equipos y máquinas hasta un determinado
momento, pero a partir del cua l es imprescindible la definición y selección de éstos. Los
equipos y máquinas pueden quedar obsoletos o sufrir variaciones importantes en sus
costes o prestaciones.

TEO RÍ A DEL PROYECTO TECNOLÓGICO
Una ·clasificación bastante representa t iva de los proyec t os industriales, con

independencia de su origen , podría se r:
• Grandes proyectos de inversión . Realmente este tipo no se puede considerar un

proyecto, sino más bien es un estudio económico que lo acompaña, tanto
desde el punto de vista de la demanda p r evista como de los costes de
producción y de sus consecuencias sociales y po líticas: creación de empleo,
desa r rollo regiona l , etcétera. Dependiendo de sus resultados indica si el
proyecto tiene o no futuro en el mercado. Si sus resultados son negativos, los
proyectos suelen morir sin ver la luz y si son positivos , se utilizan como base
para las posteriores etapas del proyecto, que habitualmente implica grandes
inversiones.
• Instalaciones y plantas industriales. La realización de estos proyectos

constituye el capítulo más amplio e importante dentro de la ingeniería industrial
y para ello es necesario la construcción de plantas e instalaciones, que
constituye un proyecto completo con todas sus fases y aspectos .
< Los sectores, instalaciones y plantas más típicos son los que se enumeran a
z
<
V continuación:
B
"'<
o Industria electrónica.
~
Robótica y automática.
"'
"'w Industria de transformación.
>
:3
z Plantas de proceso (refinerías, petroquímicas, fertilizantes, química
'"
V
<
o
z
inorgánica).
::>
u.
Industria de la alimentación.
Farmacia.
Pasta , papel y cartón.
Cemento.
Centrales eléctricas (hidráulicas, térmicas, nucleares).
Siderurgia y meta lurgia.
Industria aeronáutica y espacial.
Industria naval.
Líneas y unidades de producción.
• Unidades y líneas de producción . El estudio y diseño de las unidades y líneas de

p roducción de los edificios e instalaciones que forman las grandes plantas
industriales constituyen por sí mismos proyectos independientes que , en
muchas ocasiones están interconectados.
DIRECCIÓ N Y GESTIÓ N DE PROYECTOS TI C 19

TEOR ÍA DEL PROYECTO TECf, OLÓG:CO
FUNIBERfj
• Máquinas, equipos y sus elementos . El estudio de las máquinas y equipos que

forman parte de cualquier instalación industrial, e inc luso algu nos elementos de
éstos constituyen también por sí mismos un proyecto.
Otra clasificación de los proyectos industriales pod ría ser : según la naturaleza del
proyecto (especialidad) , el v olumen de la inversión, el objeto del proyecto y el proceso
que utiliza.
• Por la naturaleza del proyecto . Por su naturaleza o especialidad , hay que recurrir
a la clasif ic ac ión de los distintos sectores industriales. Esta clasificación
coincide con la li sta enume r ada anteriormente en el punto "i nstalaciones y
plantas industriales" .
• Por el volumen de la inv ersión .
Pequeño .
Mediano.
<
Grande. z

z
~
z
Mejora : -o
ü
<
o
z
Económ ica: Aumento de calidad , Reducción de costes. "
u.
Social: Seguridad, Protección ambiental.
Mantenim iento.
Trasl ado.
• Por el proceso que utiliza .
Su naturaleza {mecánico , físico, físico -quím ico).
Su origen (propio , de terceros).
Propietario del proceso .
Empresa de ingeni ería licenciada.
Suministradores de equipos princ ipales.

TEORÍA D::L PROYECTO TECNOLÓGICO
Quienes estudian los 'proyectos' han distinguido que existe un inmenso mar de
aportaciones teóricas y prácticas las cuales pueden clasificarse en tres tipos: teóricas ,
metodológicas y aplicaciones.
• Herramientas . Aquí se distinguen, por ejemplo, algunos software como MS Project,

técn ic as de diseño como O FD o de diagramación como los flujog r amas , y
herramientas de evaluación económica.
• Metodologías. Se consideran aquí diversos planteamientos metodológicos o

métodos de índol e general para Project M anagem ent y Dir ección de Proyectos o
métodos más específicos de ejecución de proyectos , como las metodo lo gías de
desarrollos de sistemas de información.
• Teorías . Grupo donde se aglutina n las aportaciones más abstractas y conceptuales ,

z< que intentan dar un marco integrador a las herram ientas y metodologías.
 Un a Teoría de Proyectos es un núcleo de bases teóri cas y conceptuales con las
"<
¡... cuales se sostiene un punto de vista particular respecto de lo que es un
;¡;
"' proyecto. El fin de una Te oría de Proyectos es fortalecer y mejorar el aspecto
~
3 práctico .
z
o
ü
<
o
z
Una de estas teorías es la formulada por Blasco , qu ien usa un punto de vista de
:>
LL sistemas p ar expl ic ar un proyecto. Según esta teor ía, en un proyecto pueden
§;1
distinguirse dos ti p os de subsistemas conceptuales.
b) Subsistemas conceptuales .
El proyecto es un sistema dentro del cual se intenta conseguir la solución a un

co n flicto. Esta solució n se consigue gracias a la presenc ia en un tiempo y en
espacio común y bien definidos dos subsistemas de naturaleza conceptual más
que real:
El sistema proyecta r destinado a encontrar la solución.
El sistema proyectado que será la solución al conflicto .
En ambos sist emas se manifiestan actividades mentales y de trabajo físico

(materiales) , tanto para tomar d ecisiones como para ir construyendo la
so lución. Estas actividades pueden usarse pa ra va rios fines , dando lugar así a
dos dist i nciones importa nte s en un proyecto: los subproyect os y las
dimensiones .
ÜIRECCION Y GESTIÓN DE PROYECTOS TIC 21

FUNIBER f~
T EO RÍ A DEL PROYE CTO TECNOLÓGICO
c) Sub proyecto s.
En un sistema proyecto las actividades mentales y materiales se pueden usar

para tareas de resolución de un proble ma, con lo cual se da lugar a:
Un proyecto de acción. Aquí se habla del designing , el proceso creativo de

encontrar la solución con actividades creativas como el brainstorming y con
actividades de trabajo físico como la generación de diagramas.
Un proyecto productor del artefacto (o la solución). Aquí se habla del

proyecto técnico, el proceso de concretar la solución, en la cual se incluyen
activ idades creativas como la división func iona l del producto en un Work
Breakdown Structure (WBS) y como actividad física la construcción de una
maqueta o el mismo artefacto .
d) Dimen siones .
Cuando las actividades mentales y materiales se agrupan para distinguir labores

de adm inistración y de construcción , se tienen dos dimensiones , una de gestión
y otra de construcción . En este caso, la literatura habla de procesos de gestión
<
z
de proyectos y de procesos orientados al producto. <
~
"'~
Los Procesos de Gestión de Proyectos describen, organizan y ayudan a <
~
w
completar el trabajo de un proyecto . "'<
Los Procesos Orientados al Producto especif ican y crean el producto o "'
<
t
V>
servicio del proyecto . Este tipo de proceso se define por el ciclo de vida de "~
z
un proyecto y varía por área de aplicación. :o
z
~
u
No existe una relación clara estos dos tipos de procesos, depende de cada <
Q
z
proyecto. Lo habitual es intentar hacer un paralelismo entre ellos, no obstante , :::>
u.
en proyectos grandes, cada fase de construcción se gestiona como un

proyecto.
Teóricamente , un proyecto tecnológico no es distinto de cua lqu ier otro, salvo en su

objeto : un cambio organizacional que afecta el ámbito de negocios por la influencia y
uso con veniente y oportuno de las tecnologías de la inform ación .
Y , como tal , la operación de un proyecto de e-Business comprende la ejecución de una

serie de actividades de gestión y de construcción tend ientes a pro veer una determinada
solución tecnológica a una estrategia de negoc ios .
22 DIRECCION Y GESTIÓN DE PROYECTOS TIC

TEORÍA DEL PROYECTO TE CNOLÓGICO
Este planteamiento teórico y operacional de un proyecto e-Business muestra la multi-

dimensionalidad de este tipo de proyectos, reflejado en la . En un proyecto e-
Business distinguimos la concurrencia de:
• Dos dimensiones: la dimensión de gestión y la dimensión de construcción.
• Dos visiones : visión de negocios y la visión tecnológ ica.
Dimensión de construcción Dimensión de gestión
Visión de negocio
<
z

z
::>
z
·O
u
<
o Visión tecnológica
z
=>
LL
Figura 1.4: Elementos en un proyecto e-Business.
Según esto último, en el proyecto e-Business concurren una serie de conocim ient os. La
destaca los tipos de conocimientos a considerar:

T EORÍA DE L PRO YECTO T ECNOLÓGICO
FUNIBER
D1mens1ón de gestión
Metodología de Gestión
1mplantac1ón tecnológica I' de proyecos
Por e¡emplo: proyecto de nuevo mercado,

Proyecto proyecto de nueva linea estratégica,
de negocios o proyecto de sistema de 1nformac1on
\
\
Por e¡emplo: proyecto de 1ngen1ería
\¡
Proyecto {
de softv.are, proyecto de infraestructura
Tecnológico de comunicac1ones o proyecto
de sistema 1nformát1co
Figura 1.5: El proyecto e-Business como la integración de la dimensión de construcción y de gestión, con la <
visión del proyecto de negocios y con la visión del proyecto tecnológico - en general- . "'<
:;;
::>
z
::>
De esta manera , las dimensiones permiten construir la iniciativa o solución tecnológica z
s
en una organización ( ) como un conjunto de aplicaciones de base tecnológica
), operando dentro de los sistemas de trabajo bajo una óptica de negocios y
tecnológica.

Administración
Personal
Finanzas y contabilidad
Alcance de una solución

tecnológica organizacional,
por ejemplo e-Business
Diseño y Servicio
Marketing Ventas
producción post-venta
<
z
<
~
"'~
Figura 1.6: La solución e-Business: visión del negocio.
<
o
~
"'
Administración
Personal
Sistemas de
producción
integrado Finanzas y contabilidad
Sistema de logística y
Seguimiento de productos
Diseño y 1 Servicio
Marketing Ventas
Figura 1.7 : La solución e-Business: visión del proyecto tecnológico.

T EORÍA DEL PROYECTO T ECNOLÓGICO
1.4.1 VISIÓN DE NEGOCIOS Y TECNOLÓGICA
De una u otra manera, un proyecto e-Business comprende una visión de manejo

integrado de la información organizacional, cuya puesta en escena puede abordarse
como un proyecto de sistemas de información. En este caso se distingue la visión de
negocios y la visión tecnológica.
• La visión de negocios aporta e introduce el marco organizacional y estratégico

dentro del cual se enmarca todo el proyecto e-Business, vale decir, es la visión que
sostiene la iniciativa o solución tecnológica. La implantación de esta visión se
traduce en un proyecto de negocios, entendido como todo el proceso gracias al
cual una idea de negoc ios se concre t a.
• La visión tecnológica aporta al proyecto tecnológico un habilitador y un facilitador

tecnológico . Por ejemplo, en un proyecto e-Business, la visión tecn ológ ica aporta
elementos, tanto para el propio proyecto (por ejemplo , herramientas para un e-
<
Project donde usar desarrollos RAD cuya gestión se sustenta en un software MS z
<
u
project) como para la solución e-Business (Internet, redes WAN, etc.). ~
"'o<
~
"'
1.4.2 DIMENSIONES DE GESTIÓN Y DE CONSTRUCCIÓN
Como todo proyecto, un proyecto e-Business requiere identificar una dimensión de

gestión y otra de construcción.
• La gestión del proyecto aporta un conjunto de instrumentos que permiten conseguir

los objetivos de un proyecto cualquiera. Como parte de la gestión, se debe
considerar la visión de negocios y la utilización de tecnolog ía.
• La construcción del proyecto, expresada de mejor manera como la metodología de

un proyecto e-Business , permite conducir el proyecto inte grando la visión de
negocios que lidera la idea organizacional y la visió n tecnológica que sustenta la
estrategia de negocios.

GESTIÓN DE PROYECTOS
Capí lo 2
r
GESTION DE PROYECTOS
..
z
<
u
I!"'<
~
"'"'
- Comprender la noción de proyectos y el rol que ocupa el PMBOK en la constitución de un cuerpo doctrinal
internacional de gestión de proyectos.
- Conocer algunas de las principales herramientas y técnicas empleadas en la gestión de proyectos.
- Conocer el rol de los modelos de madurez de gestión de proyectos y comprender la importancia del
aprendizaje incremental de prácticas de gestión.
- Caracterizar Marcos de referencia para mejorar el rendimiento, valor y control sobre las inversiones en TI
(Tecnologías de la Información) de las organizaciones.
- Describir los alineamientos de gestión de TI reconocidos mundialmente; la metodología de control por

objetivos CobiT, fil y SGSI.
Gestión de Proyectos es una dimensión dentro de un proyecto y no es en sí el proyecto

( ). Esto muestra, por una parte , la dependencia de la gestión de proyecto al
tipo de proyecto dent ro del cual participa y , por otra parte , la existencia de una serie de
limitaciones debidas a la existencia y oportunidad de determinados recursos,
DIR ECCIÓN Y GESTIÓN DE PROYECTOS TIC 29

FUNIBER
imposiciones y condiciones del medio, y compromisos y restricciones organizacionales .

Todo en su conjunto produce un paquete de documentación, el cual contiene y refleja la
historia del proyecto en todas las áreas en que se haya desenvuelto, y la evolución del
resultado finalmente obtenido.
Imposiciones y condiciones
del medio
Recursos humanos Compromisos y
materiales y restricciones
económico-financieros organizacionales
,. ,.1 l
T
Documentación del proyecto
Gestión de proyectos _J t
In1c1ativa e-Business Aplicación e-Business
Metodología
de implantación
PROYECTO E-BUSINESS
Figura 2.1: La gestión de proyectos en un proyecto e-Business.
El ca pítulo se organiza revisand o el co ncepto de proyectos en la literatura y en có mo se

org aniza su co nocimiento a través del estándar PMBOK. El PMBOK permite comprender
el alcance de la gest ión de proyec to s y el ins tr umenta l que emp le a y cómo deb e
organizarse en un proyecto. A con t in uación se revisan una serie de modelos de madu rez
de gestión de proyectos, que permiten introducir la idea de madurez y ap rendizaje con
relación al uso e interior ización o rganizacional d e buena s prácticas d e gestión de
proyectos. Se amplia la idea de buenas práctic as con la revisión de los ll amados marcos
de referencia, que son grupos de buenas prácticas focalizados en conseg uir resultados
de cal idad en dete rminado s aspectos de un proyecto tecnológico. Cabe seña lar aquí que
muchos de los modelos y marcos revisados han nacido o han crecido en el campo de la
informática o las TIC, pero se presentan en este cap ítulo po rque han am pliado su campo
de utilidad y ap licación hacia otras di scip lin as que les u san o que han derivado su s
propios modelos o marcos. El capítu lo se concluye con la re visión del enfoque de
gestión de proyectos PRINCE2 , el cual se complementa con el PMBOK .

FUNIBERf~ .-imm..._ . . -..................-....:._.... _..._ _
Gestión de Proyectos es una dimensión dentro de un proyecto y no es en s í el proyecto.

Por ello es conveniente revisar de qué manera el proyecto englobador cambia la visión a
tene r respecto de cómo usar la gestión de proyectos.
La gestión de proyectos intenta conseguir una planificación coherente con los objetivos
de una organización y del propio proyecto, igualmente que el desarrollo del pro y ecto se
acerque a lo planificado y supere las vicisitudes del medio y del día a día.
<
z

z
::i
z
-O
ü
<
o
z
::>
u. Planificación Desarrollo
Figura 2. 2 : Misión de la gestión de proyectos: planificar y desarrollar el proyecto.
Se encarga de planificar , dirigir y controlar el desarrollo de un sistema aceptable con un

costo mínimo y dentro de un período de tiempo especifico .
Como una manera de proveer un lenguaje universal y común entre los profesionales de
proyectos, el Project Management Jnstitute ha desarrollado el PMBOK , un documento
con el cual se espera que la práctica de gestión de proyectos se convierta en un cuerpo
doctrinal y referencial para los p rofesionales del área. Por esta razón se presenta la
gestión de proyectos desde el punto de vista del PMBO K.
En el capítulo 1 se planteó que el concepto de proyectos difiere según diversas vi siones ,

además que un proyecto es un sistema dentro del cual coexisten dos dimensiones, la de
gestión y la de construcción. Según esto, la gestión de proyectos es un sistema que
debe construirse y ser adaptado al punto de vista de proyecto que se m aneje .

FUNIBER ~
GE STIÓN DE PROYECTOS
• Proyecto como producción de artefactos. Aquí po r gestión se entiende la

programación de actividades y ver que se cumplan .
• Proyecto como consecución de objetivos . Aquí el proyecto es un conjunto de

actividades concretas para un determinado resultado, y la gestión intenta que tales
actividades cumplan con las necesidades pr esupuestas de antemano , siendo en
esencia una anticipación a un objetivo o a un estado de realidade s predefinidas .
• Proyecto de acción . Aquí el proyecto persigue finalidades , sin necesidad de seguir

un plan de trabajo . El proyecto es actuar siguiendo finalidade s o fines y la gestión
es poder anticiparse a las transformaciones o cambios de estado del proyecto y del
entorno que se producen conforme la finalidad se va alcanzando o alejando.
Para ilustrar las diferencias entre el tipo de gestión de proyectos que uno u otro tipo de
proyecto requiera , se puede decir lo siguiente:
• en los primeros dos casos, el gestor de proyectos parte de que conoce qué
conseguir y para ello busca y se nutre de varios cómos , cuándos , quiénes y z<
:
<
~
w
• en el último caso , el gestor de proyectos debe ayudar a buscar el qué se desea, "'
<
para lo cual dispone de varios cómos que le ayudan a conseguir el qué. ;;;
<
~
"'
::¡
::z
Sin embargo, aceptando cierto grado de formalización respecto de la gestión de ::i
pro y ectos asociada al proyecto como productor de artefactos, debido a que es más -~
ü
<
sencillo controlar y regular recursos respecto cuando hay una meta clara , que cuando o
z
:>
u.
ella no existe (en este caso la meta es conseguir una meta) , Kerzner sugiere que gestión G
de proyectos es 'la planificación , organización, di rección y control de los re cursos de
una empresa para un objetivo de relativo corto plazo que ha sido establecido para
c ompletar y conseguir metas y objetivos específicos'.
Siguiendo con esta primera acepción , Kirsch señala que gestión de proyectos es la
aplicación de técnicas , métodos, he rr amientas y heurísticas formales e informales, las
cuales emplea un gestor de proyectos en la motivació n y guía de un equipo de personas
para llevar un proyecto dentro de un conjunto dado de restricciones .
Visto así, la gestión de proyectos pone a disposición de los gestores de proyectos un

conjunto de instrumentos de trabajo que le permiten asumir un proyecto y superar sus
vicisitudes tal que: se anticipe a los problemas, mejore el hacer futuro, y actúe de forma
adec uada ante eventos no presupuestados.
32 D IRECCIÓN Y GE STION DE PROYECTOS TIC

f~
FUNIBER
·.
------------------------------------
En todo caso, debe tenerse claro que la gestión de pro yecto s es un medio a disposición
del gestor para construir una solución dentro de las mejo res condiciones para quienes
están dentro del proyecto y para quienes se beneficiará n de l uso del producto o servicio
resultante.
Por este motivo, el gestor de proyectos es una persona cuyo f in es h acer uso armon ioso
de una serie de re cu rsos intelectuales (conocimiento , creatividad ) y co rpó reos (trabajo
físico , esfuerzo mental ), con especial cuidado y atención a las per sonas. Es una la bor
donde especialistas actúan con libertad como parte de un todo ( ).
"'
"'>-"'
;;;
~
~
z
::>
z
-O
ü Figura 2.3: El fin de la gestión del proyecto.
<
o
z
:>
u.
El gestor de proyectos se destaca como la figura clave en la pla nificación , ejecuc1on y

control del proyecto y es el motor que ha de impulsar el av ance del mism o med iante la
toma de decisiones tendentes a la consecución de los objetivos. El gestor de proyectos
es un verdad ero jefe, es dec ir, tiene poder ejecuti vo y autoridad p ara ma ndar y tomar
decisiones dentro del ámbito y objetiv os del proyecto. No es un mero coord in ador o
animador, como en algunas ocasiones se piensa. De la misma forma , t ampo co sería
correcto pensar que el gestor de proyectos tiene un pode r absoluto y dictatoria l sobre el
mismo, ya que se encuentra inmerso en la estructura y organización de la em presa.
La s r elaciones básicas del gestor de proyectos c on otras u nidades o person as

dependen, en gran medida , de la est ruct ura o rg anizativa que posea la org anización
( ).
DlRECCIÓN Y GESTIÓN DE PROYECTOS TIC 33

FUNIBER~
GESTI ÓN DE PROYECTOS
Suministrador
de conocimiento
Organización
Dirección de
la empresa
t
Directores de Director Informes
otros proyectos de proyecto Clientes
Instrucciones
~~~
~ "'~
~ · Personal
asignado 1
al proyecto
Proveedores Contratistas Relaciones Organismos

de equipos construcción públicas oficiales <
"
información sobre instrumentos y prácticas que se pone a disposición de pe rso n as para "
:::>
hacer un uso ópt imo y robust o de recursos bajo su responsabil idad frente a restricciones "
·O
u
o<
y contingencias para el cumplimiento de metas t r azadas de antemano . Todo lo anterior ""
u.
relacionado con tres parámet ros clás icos de gest ión: tiempo, coste y desempeño, para G
mejo rar la calidad y consegui r un riesgo cero.
No obstante, el valor agrega d o de esta info rmación depende rá de la utilidad que le

otorgue el gesto r del proyecto: conseg uir lo qu e se le pide, resolver un conflicto,
aprender del h acer h aciendo y, sali r airoso de las v icisitudes d iarias. Esto dependerá de
la habilidad que adquiera, tanto por capacid ad personal como resultad o de un proceso
de formacional.
Por último, existe el caso de una gestión or ientada a dar un valo r espec i al al gesto r
como evaluador de opciones futu r as, tal como se ilustra en la , an te
vicisitudes.
34 DI RECCJÓN Y GESTIÓN DE PROYECTOS TIC

GE ST I ÓN DE PROYECTOS
_ _lllml_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
FUNIBER 1j
<
z
<
u ... Les quedaré muy agradecido si se
«
w
:¡: amotinan y me abandonan en un bote ...
<
~
w
"'
Figura 2.5: La gestión y sus vicisitudes.
Cabe añadir que dado que todo el instrumental existente

para la gestión de proyectos ha si do diseñado y especi ficado para
grandes compañías, se hace necesario hacer una redefinición de este
p instrumental con el fin de lograr un modelo destil ado o filtrado de

mejor aplicación en compañ ías con recursos lim i tados. De esta manera,
al momento de aplicar la gestión de proyectos en una pequeña o mediana
empresa, queda en evidencia la importancia del juici o profesional y de
entender cómo se estructura y opera este tipo de empresas, lo cual
precisa y hace necesario anal izar los p r o y c on tra s de cada una de
l os diversos instrumentos desde el punto de vi sta de s u ap lica ci ón
rea l en este tipo de empresas.
La forma de organizar lo s esfuerzos y experiencia de gestión de pro y ect os se han

llevado adelante mediante el arte de las personas en el rol de gesto r de un proyecto o
va r io s (programa) . Organ izar todo aquello en un cuerpo doctrina l forma l se h a visto
dif ic ultado por dos razones:

FUNIBER~
• No se ha m anifestado un cuerpo o núcleo central al cua l ceñirse los gestores para

recabar experiencias y tener un do m inio com ún de discusión.
• La gestió n de proyectos es cultu ral , pues depen de de las características y

singu lar idades del grupo de personas que co nstituye y se relaciona con el proyecto.
Estas razones han hecho que hoy en día exist an dive rsas asociaciones dedicadas al
estudio de proyectos tales como:
• AEIPRO. Asociación Española de Ingeniería de Proyectos.
• A FITEP. Association Francophone de Management de Project.
• IPMA . lnternational Proj ect Management A ssociation.
• PMI. Project Management Jnstitute.
• SMP . Société suisse de Management de Project.

<
z
<
Project Management lnstitute . El Project Management lnstitute (PM 1) es una u
organización internaciona l or ientada a la difusión y determinación de las mejores

a
"o
<:
prácticas de gestión de proyectos. En este afán, produce documentos que desc ribe n "'
~
"'
<
prácticas generalmente acept adas de gestión de proyectos. "'<:
PMBOK. El más import ante de los documentos publicados en la actualidad po r el PM I es

el PMBOK , A Guide to the Project Management Body of Knowledge .
El propósito de esta guía es describir el conoci m iento y las prácticas usadas en varios
tipos de proyectos. Du rante veinte años se han estado revisando y discut iendo cuáles
son los proyectos cuyo conocimiento y estudio aporta valor y utilidad a la prácti ca de
proyectos. Este esfuerzo se ha traducido en identificar pr ácticas de gestión de
proyect os generalmente reconocidas como buenas prácticas, aplicables a la mayoría de
proyectos, la mayoría del tiempo.
La importancia del PMBOK , por sobre toda compilación y mejora de prácticas, es que
provee una base forma l para funda r proyectos , guiando y orientando a gestores de
proyectos sobre la forma de llevar adelante la construcción de resultados. Para ello , no
obstante , es menester adaptar los contenidos del PMBOK al dominio técnico de cada
proyecto en particular. Cada equipo de t rabajo será responsable de determinar la uti lidad
del contenido de esta guía para cada proyecto asignado.
Gracias al Programa de Estándares para Gestión de Proyectos promovido po r el Project

Management lnstitute, el PMI es reconocido por el ANSI (American National Standards
lnstitute) como una inst itución desarrolladora de estándares. Además, el PM BO K
actualmente es el estándar ANSl / PM I 99-00 1 - 2004 aprobado por el ANSI , es

FUNIBER ~~ ________________mm:._......_.................
GESTIÓ N DE PROY ECTOS
reconocido como estánda r por el IEEE (!nst;tute of Electrical and Electronical

Engineerings ) y sirve como referencia para el manejo de proyectos informáticos para la
ISO (lnternational Organization for Estandarization ). Esto hace pensar que las prácticas
incluidas en el PMBOK son bien aceptadas a ni vel mund ial, y su util idad se refleja en
cualquier ámbito.
Gestión de proyectos según el PMBOK . Según el PMBOK , gestión de proyectos es la

aplicación de conocimiento , herramientas y técnicas a activ idades de un proyecto con el
fin de satisfacer los requerimientos del proyecto. Todo este conocimiento, habilid ades ,
herramientas y técnicas se distribuye y usa a lo largo de varios procesos de gestión de
proyectos.
Cada p roceso de Gestión de Proyectos pe rtenece a un Á rea de Co nocimi ento de

Gest ión de Procesos y se asocia a un Gru po de Procesos de Gestión ( ).
<
z
 Proceso de ;-------~
z
-O
ü
gestión
<
e
pertenece
z
::>
u..
Q
Figura 2.6: Componentes del PMBOK y sus relaciones.
La finalidad del PMB OK como guía no es la de exponer las disciplinas, técnicas y

experiencias aplicables a la dirección de proyectos , sino si m p lemente la de identif icar el
subconjunto de éstas que es generalmente reconocido como buenas prácticas. Por esto
mismo , es necesario adaptar los contenidos de l PMBOK al dominio técnico de cada
proyecto en particular. Por eso se hace necesario que cada equ i po de trabajo sea
respons able de determinar la utilidad del contenido de la gu ía PMBOK de acuerdo al ti po
de proyecto asignado, lo que exige en el equipo buena experiencia en la gestión de
proyectos pa r a tener conocimiento de cuáles partes de la guía aplicar según las
particularidades del proyecto a gestionar.
Ante esto último, qu ien sea el líde r del proyecto será la persona responsable de cumplir
con los objetivos del proyecto y para ello debe tomar dec isiones sobre cómo lleva r
adelante la gestión del proyecto , lo que le compromet e a:

FUNIBER ·1~
GES TIÓN DE PROYECTOS
• Identificar requer imientos.
• Establece r objetivos claros y verdaderamente logrables.
• Equilibrar las demandas de calidad, alcance, tiempo y coste.
• Adaptar las especificaciones, pl anes, y enfoque de acuerdo a las diversas

preocupaciones y expectativas de las personas implicadas en el proyecto .
2.3.1 ÁREAS DE CONOCIMIENTO DE GESTIÓN DE PROYECTOS
Las nueve áreas de conocimiento, Project Management Know/edge Areas, se describen

en la
Incluye los procesos requeridos para asegurar que todos los elementos del
:4. Gestión de la Integración
proyecto son coordinados adecuadamente.
Incluye los procesos requeridos para asegurar que el proyecto abarca y

.:rs. Gestión del Alcance considera solamente el trabajo necesario para completar el proyecto
<
satisfactoriamente. ;;:
<
t-
¡¡;
Incluye los procesos requeridos para asegurar el término temporal preciso ~
#6. Gestión del Tiempo ~
y adecuado del proyecto. z
::>
z
-o
Incluye los procesos requeridos para asegurar que el proyecto se concluye ü
#7. Gestión del Coste <
e
dentro del presupuesto aprobado. z
"
u.
Incluye los procesos requeridos para asegurar que el proyecto satisface g
#8. Gestión de la Calidad
las necesidades para las cuales fue definido.
#9. Gestión de Recursos Incluye los procesos requeridos para organizar y administrar los equipos
Humanos de trabajo para el proyecto.
Incluye los procesos requeridos para asegurar una generación,

.#10. Gestión de las
recolección, diseminación, almacenamiento y disposición final en tiempo y
Comunicaciones
de forma apropiada, de la información del proyecto.
Incluye los procesos requeridos para identificar, analizar y responder a los

#11. Gestión del Riesgo
riesgos del proyecto.
Incluye los procesos requeridos para adquirir los bienes y servicios que el
#12. Gestión del Abastecimiento proyecto necesita e incluye además procesos de administración de
contratos.
Tabla 2.1. Áreas de conocimiento de gestión de proyectos.

FUNIBER f~ ..................a. . . . .mc......-......................
DIRECOÓHDf
PROYECTOS
4 . Gestión de la Integración 6 . Gestión del Tiempo

del proyecto del Proyecto
4 .1 DesatTollar el ilda de coostmJoón 6.1 Defontción de las ActMdades

del PIOyectO 5.1 PIJniticaoon oei Alcance 6.2 Estableomiento de la secuenoa
4. 2 Desatroilar el enunciado del 5.2 O.:f1no0on Oel Alcance de ActlVlditdes
ak:llnce del PfoyeCIO prelll!linar 5.3 Crear eor 6.3 Estimación de recursos de las
4.3 Desam>llar el Plan de~ 5.1 VcflfK:aooo <le' t..cancc Actividades
del Proyecto S 5 Contra' Del Aic.ar>ee 6. 4 EstllTlllOO!l de la duraoon de las
4.1 O.ngir y gesue>Mr la e¡ecuoon Aalllldacles
del Proyeao 6.5 DesarrollO óel cronograma
1 .S Supo!tV!Sar y controlar ei traba¡o 6.6 Control del cronograma
del proyecta
1 .6 Control ontegl'lldo de camboos
1.7 Cerrar Proyectos
7. Gestión de los Costes 8. Gestión de la l:alld~d 9. Gestión de los Recursos

del l'ro'(eáo del Proyecto Humanos d el Proyecto
9.1 Planrftcaooo de los Recursos

7.1 Est>maoón de Cos:es 8 . 1 Plan1ftúKOÓ'I oe úld.>d
Humanos
7.2 Preparaoón del presupuesto 8.2 Realtiar AsegJ•amiento
de úhdaó
9.2 Aóqwir el equ'po del f>ro\'eao
de Costes 9.3 Desam>llar el QUIPO del proyecto
7.3 Control de Cosles 8.3 Real.zar Cont•ol de Ca'><litd
9.4 Gesbc>nar el equ•po del proyecto
<
z
<
~
~ 10. Gestión de las 11. Gestión de los Ries9os 12. Gestión y dirección de las
>:
< Comunicaciones del PToyecto del Proyectxl Adquisiciones del Proyecto
o
a:
w
12 1 Plan1ftear las compras y
"' 1O 1 Planificaoon de las
11.1 Plallificaoon oe 1a Gesoon de
adqulSICiooes
::a: Comunooones
Riesgos
12.2 Plan.ftear la conttataOOO
< 11.2 ldenuficaoón oe R>es;¡os
10.2 O.stnbuoóo de la Jnlormaoón 11.3 Anál!SIS cual1:a~vos de Riesgos 12.3 Solte>tar ~de vendedores
10.3 Informar el rend1tnJe1110 12 4 Selecoón de \'eOdedores
"'~ 10.4 Gestionar a los interesados
11.1 Anál!SIS cuanbtawos oe RJCS90S
12.5 Aóminlstraaóo del contrato
> 11.S Segv1m1ento y control de RJESgOS
z 12.6 Cierre del contrato
::;¡
z
"5!
u
<
e
z Figura 2.7: Vista general de Áreas de Conocimiento y Procesos de Gestión .
::>
u..
:,Q;

FUNIBER
Para comprender un proyecto lo primero que hay que tener presente es que evoluciona según las
necesidades de adaptación que le impone el medio. Esto le lleva a buscar continuamente nuevas estructuras
organizacionales que le permitan subsistir a las diversas fases de desarrollo y a los cambios del medio,
además de buscar continuamente nuevos estados de sinergia que le permitan aprovechar al máximo los
recursos con que cuenta.
Con esto, las diversas fases de desarrollo (o construcción), a la par

de las diversas fases o etapas de gestión que se verán en el
siguiente capítulo (iniciación, planificación, control, ejecución,
cierre), incluyen actores diversos que aparecen o desaparecen en
las diversas tareas y actividades consideradas a discreción y por
conveniencia al proyecto, en roles de protagonista o como un actor
secundario. Según los grados de participación, los actores se
posicionan dentro de la estructura organizacional del proyecto que
sea conveniente al momento, y se relacionan entre ellos según la
configuración de equipo de trabajo que se considere pertinente.
---
<
z
<
u
5
Reconocer a priori cuál será la organización del proyecto por cada :r
<
o
fase no es sencilla . Solamente se puede tener conciencia y relativa .,"'"'
certeza que en ciertas fases determinados actores son necesarios . ...-·..
con un determinado grado de participación o actividad. Según
nuestras previsiones de las tareas que cada actor cumplirá, y
....
considerando que a lo largo del proyecto nuevos y más actores
intervendrán, la figura siguiente, puede ilustrar la complejidad de
lo que involucra el proyecto.
Evolución longitudinal de la estructura
organizacional del proyecto.
-.-. --·....•
Esta situación solamente refleja la estructura organizacional del
.-···
..-
proyecto. Pero, conforme un proyecto es un transitorio, una
instancia temporal y situada de esfuerzo humano por conseguir un
resultado concreto a la solución de un conflicto social y/ u
.:fj
. ..··.·:
-...· .....
.
- ..... ....
organizacional, los actores partícipes del proyecto en ocasiones ~ --·
.::
son parte intrínseca del proyecto, o sea, contratados a tiempo y
dedicación total y absoluta al proyecto, mientras otros, y
comúnmente ocurre así, provienen de otras organizaciones tal .. ...
,.._.,.
como ilustra la figura siguiente.
Integración transversal de organizaciones
e individuos a la estructura organizacional
del proyecto.

GESTIÓ N DE PROY ::CTOS
FUNIBER 'f j m-=111m1._.........._.macum....-ram. .. _. . . . . . . .- -
Mientras la evolución longitudinal obliga a tratar con la

complejidad del cambio continuo, la integración transversal obliga
a resolver el problema continuo de mantener la cohesión del
proyecto especialmente cuando hay actores que pueden mantener
compromisos con las organizaciones de donde provienen. Esta
situación obliga a precisar entonces que un proyecto es una
sucesión de encuentros de personas a lo largo del t iempo,
encuentros que son ni más ni menos que reuniones de trabajo
donde los actores, sea cara-a-cara o a distancia, exponen sus
avances, resuelven problemas y comparten experiencias.
El proyecto como un esfuerzo
comunicativo.
Con esto, se intenta dejar en claro que el proyecto finalmente es

un esfuerzo de comunicación cuyo fin es la cohesión e integridad
estructural del grupo constitutivo del proyecto.
<
z
< Y, con esto, se tiene en claro que el principal problema del jefe o
u
"'>:w director de proyecto es crear, sostener y apoyar los lazos de

<
o
comunicación.
~
<
;;:
....<
Fuentes:
"'"'w Torrealba, Alvaro. (2000). La organización del proyecto. En Cuadernos de lngenleria de Proyectos 111: Dirección, Gestión y
!:
z Organización de Proyectos. Universidad Politécnica de Valencia. Valencia-España: UPV. 238 pp.
::>
z
·O
Estay, Christian; y, Blasco, Jaume. (2000). El universo de proyectos: una epistemología sistémica para proyectos. En V
ü
<
lnternatlona/ Congress of Project Engineering. Lle/da, España. 4-6 Octubre.
o Blasco, Jaume; Cisteró, Manuel-Jordi; Cremades, Lazara V.; Estay, Christian A.; García, Águeda ; Gracia, Santos; y,
z
::>
u.. Masarnau, Joan. (2001). Experiencia docente presencial-no presencial colaborativa en la formación de Proyectos. En 111
Jornadas Multimedia Educatiu. Barcelona, España. 25-26 Junio.
Tabla 2.2. Nota sobre los proyectos y su constitución comunicativa.
a.- Gestión de la integración
La gestión de integración del proyecto incluye los procesos y activi dades requeridos
para asegurar que los diferentes elementos del pro yec to son coordinados
adecuadamente. Se ocupa de encontrar el equilibrio entre los objetivos posibles y sus
alternativas, con el fin de satisfacer o colmar las necesidades y expectat ivas de las
entidades involucradas en el proyecto. Mientras que todos los procesos de dirección de
p r oyectos son de alguna forma integradores , los de esta área lo son de mane ra
fundamental. La proporciona una v isión general de los siguientes principales
procesos.

FUNIBERf~
G ESTIÓN DE PROYECTOS
La Integración implica tomar decisiones con respecto a la can t idad y el momento en que
se concent ran los recursos y esfuerzos, al adelantarse a los hechos; además de
coordinar las ta re as por el bien del proyecto.
GESTIÓN DE LA INTEGRACIÓN
DEL PROYECTO 1
/ '
4.1 Desarrollar eJ acta de
constituóón del Proyecto
/ 4.2 Desarrollar el Enundado del
alcance del Proyecto preliminar
4.3 Desarrollar el plan de
Gestión del Proyecto
"
l Entradas L Entradas l Entradas
• Contrato ( aiando corresponda) • Acta de consowoón del proyec;to • Enunoado del alcance oe p"O)'ecto
,_____ - Enunoado del traba¡o del proyecto >--- - Enunoado del traba¡o del proyecto ,___ preliminar
- Faaores amb1er.tales de la enpresa - Factores ambientales de la empresa • Proceso de d"ecaón de proyectos
- AclJvos de los procesos de la • Activos de los pcocesos de la • faaores ambtenrales de la em~resa
organiZaoon or;¡amzación - Activos de los p'oces..--s de la
2 H1.:. ·ramit::ntas y t~cr.1c:as 2. Herram!er.!25 y tknicas cri:¡,,.-1 dC1 .:n
- Metodos de selecc1on del proyecto • Metodología de d·rec--.ión de 2. Herramientas y tecn1cas
- Metooología de direcaón de proyectos - Metodología ae airecoo~ ae
proyectos - S!stema de 1nformaaón de la proyectos
- Sistema de información de la gestión de proyectos - Sistema de informaooo de la
gestJon de proyeaos • JUICIO de expertos gestión de proyectos
- Ju1ao de expertos 3. Salidas - Ju1ao de expertos
3. Salidas - Enunelado del alcance del proyecto 3. Salidas
\,.
- Acta de constitución del proyecto
~
preliminar • Plan de Gestión del proyecta , <
:z
:
<
o
:;;
l. Entradas l. Entradas l. Entradas
- Plan de Gestión del proyecto - Plan de Gestión del proyecto - Plan de GestJón del prcyeao
"
- Acoones correcuvas aprobadas
>---- - Acciones preventivas aprobadas
~ - Información sobre el rendimiento
del traba}O - - c:amb<os sol1crtildos
• lnformaoón sob"e el ·end:m1e.,ro
- Sol10tu:les de cambto aprobadas • Sollatlldes de cambio rechazadas del traba¡o
- Reparaaón de defectos aprobada 2. Herramientas y técnicas - Aocianes preventJvas reco-nenaadas
- Repacaaon de defectos validada - Metodolog1a de direooón de - Aocianes correctivas recomendadas
• Procedimiento de eierre proyectos - Reparaoon de defeaos recome'ldada
adm1mstrauvo - Sistema de infórmaaón de la - Productos entregables
2. Herramientas y técrncas gestion de proyeaos 2. Hei-am1entas y técrucas
- Metodología de direcc10n de - Tecnica del valor ganado - Metodología de direcoon ae
proyeaos - Juicio de expertos proyectos
- S•stema de mformaaón de la 3. Sahdas - Sistema de mformaoó, de la
gestión de provectos - Acaones correcuvas recomendadas gestión de pro)'ectOs
3. Salidas - Acciones prevenbvas recomendadas - JulClo de expertos
- Productos entregables - Proyecoones 3. Sa,idas
- CamblOS soliotados - Reparaoón de defectos recomendada - Solic1rudes de cami,10 ap,ot>adas
• Sohatudes de cambto 1mplementodas " - Camti.os sol1CJtados • S0Uc1tudes de cambio rechazadas
- Acciones rorrecuvas implementadas - Plan de GestJón del pro¡·ecto
- Acciones preventivas 1mp1ementodas (actual1:aaones)
- Reparación de defectos implementada - Enunoado del alcance de' p·oyecto
- lnformaaón sobre el rend1m1ento del (actualaaaones)
trabaJO - Acciones corree-uvas aprobadas
- Acciones preventivas ap•obadas
- Reparaoón de defectllS aprobada
- Reparaoón de defeaos va"dada
/
4.7 cerrar proyttto "' \,.
- ProduC1os entregables ,)
l. Entradas 2. Herram•entas y tecnlcas

- Plan de Gestión del proyecto • Metodología de d1recc1ó, de p-oyeaos
- Documentación del contrato - Sistema de 1nformaaón de la gestión
- Factores ambientales de la empresa de P:'Q\'ectOS
- - ActJvos de los procesos de la organ12aaó,
- lnformaoón sobre el re.,d1m1ento
- JuiclO de expertos
3. Salidas
del traba}O - Proced1m1ento de aerre aom1nistrat·vo
- Productos entregables - Procedimiento de aerre de rontrato
• Produao. serviao o resultado fina'
- t.."'tivos de los procesc.s de la º'ganizació.1
\.
(aauahzaciones) ,
Figura 2.8: Visión general de la Gestión de la Integración del Proyecto.

Sin embargo, para que un proyect o sea completado con éxito, también debe produc irse
la integración de otras muchas áre as. Por ejemplo:
• El trabajo del proyecto debe ser integrado con las operaciones en curso de la
organización ejecutora, la metodol ogía e-Business, po r ejemplo.
• Deben integ rar se el alcance del producto y del proyecto.
• Deben integrarse los re sultados de las distintas especialidades funcionales (como

pueden ser las especificaciones de la arqu itectu ra e-Business o los planos
eléctricos, mecánicos y civiles en un proyecto de ingeniería ).
b.- Gestión del alcance
La Gestión del Alcance del proyecto comprend e los procesos requer idos (ver
para asegurar que el proyecto contiene todo el trabajo necesa rio y solamente el trabajo
necesario, para completar el proyecto con éxito . Esta área está relacionada
z< principalmente con la definición y control de .l o que está o no está incluido en el
<
~
"''"':¡: proyecto. En esta área se amplía y detalla el alcance, a manera de continuar con el
<
o alcance prel im inar definido en el área de Integración.
~
<
;;:
< En el contexto del proyecto, la palabra 'a lcance' puede referirse a lo siguiente:
~
"'
"'
w
>
z
:::> • Alcance del producto : son las características y funciones que deben inclui rse en la
z
·O
ü iniciativa o solución e-Business.
<
e
"::>
u.. • Alcance del proyecto: es el trabajo que debe llev arse a cabo para entregar una
aplicación e-Business con las características y funcio nes especificadas.
La gestión del alcance debe considerar los siguiente:
• Los procesos, herramientas y t écnicas empleados para dirigir el alcance del

producto son d iferentes según sea el área de apl i cac ión y norma lmente son
definidos como parte del ciclo de vida del proyecto, el cual puede ser la
metodología e-Business y/ o el modelo de desarro llo en un proyecto in formá tico.
Lo que debe tenerse cuidado , es que un proyecto consta de un único producto,

pero este producto puede tener elementos auxiliares , cada uno de ellos co n su
propio alcance del producto, separado pero interdepend ient e.
Por ejemplo , un nuevo sistema te lefónico general m ente incluirá cuatro elementos
auxiliares: hardware, software, formación e instalación. En el caso de una iniciativa
e-Business, cuya solución es una aplicación e-Business, el la constará de una serie
de hardware, software y procedimientos de trabajo vinculados a la manutención de

FUNIBER f~~
G ESTI Ó N DE PROYECTOS
la arquitectura e-Business y de un conjunto de apli c2 ciones de software específicas

y procedimientos de operación ligados que permite n la operación de la aplicación e-
Business.
La comprobación de que se ha completado el alcan ce del producto se realiza según
los requerimientos del mismo, mientras que el alcance del proyecto se real iza según
el plan del proyecto. Estos dos tipos de gestión del alcance deben estar
perfectamente integrados para asegu rar que los trabajos del proyecto darán como
re sultado el producto especificado .
GESTIÓN DEL ALCANCE

DEL PROYECTO
r r 'I
5.1 Planificaci6n del alcance ' 5.2 Definici6n del alcance 5.3 Crear EDT
1 Entradas l. Entradas l. Entradas

- Factores ambtentales de la - Acbvos de los procesos de la • Aal\/OS de los proa!S05 de la
empresa organuaoón organllaoón
- Activos d'! los procesos de la - Actl! de coostltUOÓn del proyectO • Enunoado del a'cance del proyeao
orgaruzaaon • Enunaa~o del ale.axe del proyecto - Plai de gestión del alcance del
- Acta de cons:.tuoói del proyecto preliminar proyec!O <
z
• Enunc•aoo del aicaice del Proyecto - Plan de gestión del alcance del • Sohol\ldes de cambio aprobadas <
~
-
pre:1m1nar
- Pian de Ges'J:>n del proyecto
2. Herramientas y técnicas
- proyeao
- SoliOWdes de cambto aprobadas
2. Herramientas y tecnocas
-
2. Herramientas y tecnocas
• Plai~llas de la estructura de
elesglose del traboa]O
"'>'
<
o
• Ju100 de expertos
- Plantillas, formulanos, normas
- Análisis del prodJcto
- loenoficaaón ele altematrvas
- DescompoS106n
3. Salidas ..
;t:
3. Salidas - Juioo de expertos • EnJnoado del alcance del proyecto <

- Plan ele Gestión del a.canee del - Anal!SIS de los interesaoos Cactuai1zadones) "'<
proyecto 3. Saioaas - Estructura de desglOSe del trabaJO ;;;
\.. ~
• Enunciado del alcance del proyecto "°
- o.ooona de la EDT ~
- cambios sol10tados -unea base del alcaice del proyeao >
- Plan de gesbÓn del alcance del (actuahzaoonesJ ::>
proveao (aavahzaoones) - camboos sohcm•dos
\.. ~ ~ 5
V
<
¡r o
r
5.4 Verilicad6n del alcance 5 .5 Control del •lcanc::e ' z
::>
u.
1. Entradas l. Entradas
- Enunciado del alcance del proyecto - Enunaado del alcance del proyecto
- Olccoonano de la EDT - Estrucrura de desglose del trabajo
- - Plan de gesuon del alcance del
proyecto
- DICdonano EOT
- Plan de gest:icin del alcance del
- Produc:os t•rwegables proyecto
2 Herramientas 1 :eO'I cas Informes de rendimiento
- lnspecclOO - Soliotudes de cambiO aprobadas
3. Salidas • Información sobre ei rend1moemo
- Productos e'1tregables aceptados de. traba)O
- cambtos sol1otados 2. Herramientas y técnicas
\.. - Aa:iones correctrvas recomendadas - S\Stema de control de cambtos
- AnáhSJS de vanac10n
- Rep~a~1ficaoón
- • SISl.ema de gestión de la configuración
3. Salidas
- Enunoooo ckl alco,ce del proye::o
(aava izaoones)
- Estruc:Jra de desgl°"" dei t-abajO
(ac-...atzaoones)
- Docoonano de la ED7
( acl\lalczaoones)
- Linea de base del akance
( actualizaoones)
- cambios soltotados
- Acoones correctivas recomen!ladas
- ActNos ele los procesos de la
orgaruzaoón (actuahzaoonesi
• Plan de gestión del proyecte
(acl\lal:zadones)
\.. ~
Figura 2.9: Visión general de la Gestión de Alcance del Proyecto.
44 DIRECCIÓN Y GESTIÓN DE PROY ECTOS TIC

G ESTIÓ N DE PROY ECTO S
FUNIBERff ._._. . . . . . ..__.11a1am...................... . .
c.- Gestión del tiempo
La Gestión del Tiempo incluye los procesos necesarios para asegurar la conclusión del
proyecto en los tiempos establecidos. La provee una vista general de sus
procesos.
En algunos proyectos, especialmente en los mas pequeños , la secuencia de actividades,

la estimación de la duración de las actividades y el desarrollo del programa están tan
íntimamente ligados que se consideran como un único proc eso {por ejemplo , p ueden
desarrollarse por una sola persona en un período de tie mpo relativamente corto }. No
obstante el PMBOK presenta estos procesos separados y distintos porque l as
herramientas y técnicas para cada uno son diferentes.
Con respecto a esta área , la única consideración es que no ex iste consenso entre los
profesionales de la gestión de proyectos es sobre la relación entre act iv idades y tareas ,
pues:
<
z
<
u
• En muchas áreas de aplicación , se considera a las actividades com puestas por
~
:¡:
<
o
tareas. Esto es lo más normal y lo más utilizado.
~
"'
• En otras áreas , se considera a las ta reas compuest as por activ id ades.
Sin embargo, la consideración más importante no es el t érmi no que se util ice, sino si el
z trabajo a realizar es descrito de forma precisa y si es compre ndido por las personas que
-o
ü
<
o
deben realizarlo , distinguiendo claramente cuando algo se com po ne de ot ra cosa . Esta
z
:;,
u.. consideración es muy importante en un proyecto e-Business , do n de el trabajo
interdisciplinario de di versos profesionales, informáticos, eco nomistas , adm in istradores
de empresa , electrón icos , etc ., pueden manejar distint as acepcio nes de lo mismo. En
este caso , lo prioritario es fijar el glosa ri o de términos of ic iales del proye cto.
DIRECCIÓ N Y GESTIÓ N DE PROYECTOS T I C 45

FUNIBERf~
GESTI Ó N DE PROYECTOS
GESTIÓN DEL TIEMPO

DEL PROYECTO
/
6.1 Definióón de las actividades ' 6 .2 Establecimiento de la
secuencia de las actividades
' 6.3 Estimación de recursos de
las actividades
- Factores ambientales de la - Enunoado del alcance del proyecto - Factores ambientales de la empresa
empresa - Lista del actividades - ActNos de los procesos de la
- Activos de los procesos de la • Auibutos de la actMdad organizaoón
organ1zaoón - Lista de hitos - Lista de actlVidades
- Enunciado del a!caxe del proyecto - Solteitudes de cambio aprobadas - Amburos de la acov1dad
- Estruaura de desgl:ise del rraba¡o 2. Herra'l'11entas y tecmcas - D1spon1blhdad de recursos
- Dtroonario EDT
- - Plan de gesuón del proyecto
,___
- l'l<?todo de diagrar-.adón por
precedenaa (PDM)
- Metodo de dtag•ama:ión con
-
- Plan de gesu6n del ~royeao
2. Herramientas y tecn1cas
- Juico de crpertos
- Oes-'Ompos1aón flechas (ADM) - Anah5's de altemanvas
- Plantlllas - Planttllas de rea de; cronograma - Datos de est:maaones publicados
- Planificaaon graouar - Determ1riaoón de dependenoas - Softwa"' de gesn6n de proyectos
• Ju1ao de f?XPértos - Aphcaoon de aoelantos y retrasos - Est1macion ascendente
- Corrponente d pla'"' "1cación 3. Sahca· l s..:icas
3. Salidas - Dlagrarria de red del cronograma - Requisitos de recursos de las
- llsta de acmndades del proyecro acnv1dades
- Alnbutos de la actividad - Lista de actMdaóes (actl.lalrzaoones) - Atributos de la actMdall
- Lista de hitos - Atributos de la actividad (actualiZaciones)
• Cambios sohatados (aauahzaoones) ·Estructura de desglose de recu=
./
' '
• CamblOS solt0tados
~
• Calendarios de recursos
(actuala.aoones)
• Cambtos sol•atados ,
' <
z
<
r r r ~
6. 4 Estimación de la duración
6.5 De.sam>llo del cronograma ' 6 .6 Control del aonograma ~
de las actividades :?o
l . Entradas l. Entradas !. Entradas a:
w
- Factores ambientales de la empresa - Acnvos de los procesos de la - Plan de gesbón del cronograrrta "'
- Acovos de los procesos de la organizaaon - Linea base del cronog'<lma
oroanizaaón - Enunaado del alcance del proyeao - ¡,formes de rendrlTllento
- eñ'unc1ado del alcance del proyecto - Lista de acnv1dades - Sohatudes de cambto aprobadas
- Lista de acnv1dades - Atributos de la actMdad 2. Herramientas y tecnicas
- Atributos de la actividad - Diagramas de red del cronograma - ¡,forme del avance
- Requ•Sttos de recursos de las del proyecto - Sistema de control de cambos del
acnv1dades - Requisitos de recursos de las cronograma
~
- Calendanos de recursos acnvídades - Medición del rendrm•ento
- Plan de gestión del proyecto - ca lendano de los recursos - Softwa"!! de gest16n de Pro\'ectOS
- Reg>strO de nesgas · Est.Jmaoones de la duraaon de la • Anal•s1s de vanaoon
- Esttmaaones de =es de las aenvidad • Diagramas de barras de comparao6n
acovillades - P'.an de gestión del proyeao del cronograma
2. Herramientas y técn1ccs 3. Salidas
- Ju100 de expertos - • Registro de nesgas
~
• Datos de: modelo del C'Dnograma

- Estimación por analog•a - Análisis de la red del cronograma (ac:walrzaaones)
- Esttmaoon parametnca - Método del camino crítico - Linea base del cronograma
- Estimaoones por tres valores - Compre>'ISIÓn del cronograma ( actualrzaoones)
- AnáhStS de reserva • Análisis del escenano •qué pasa s1· • Med1oones del rend1m>ento
3. Salidas - N'velaoón de recursos - Cambios solicitados
- Esbrrtaoones de la duración de - Método de cadena cribca • Acc:iones correctivas reromendadas
las ac!lvidades - Software de gestión de proyectas • ActJvos de los procesos de la
- Atributos de la actMdad • Apl1caaón de calendarios organización (actuahzaoones)
(actuahzaciones) - A¡uste de adelantos y retrasos ·Lista de acttv1dades (acrualrzaoones)
~
· Modelo de cronograma - Atributos de la actmdad
3. Salidas ( aauahzaciones)
• Cronograma del proyecto - Plan de gesuón del proyecto
- Datos del modelo del cronograrria (anualizaoones) ~
- Linea base del cronograma
- Requisitos de recursos
(actuahzaoones)
• Atnbutos de la acttv1dad
(aauahzaaones)
- Calendano del proyecto
(actualizaciones)
- cambios solicitados
- Plan de gestion del proyecto
(a<llJaltzaoones)
- Plan de gestJ6n del cnn:>grama
(actuahzaoones)
Figura 2. 10: Visión general de la gestión del tiempo del proyecto.

d.- Gestión del coste
La Gestión de Coste del proyecto incluye los procesos inmersos en la planificac ión,
estimación , presupuesto y control de los costes , con el fin de asegurar que el proyecto
se finaliza dentro del presupuesto aprobado.
La provee una vista general de los principales procesos involucrados:
GESTIÓN DE LOS COSTES

1 DEL PROYECTO 1
1 1 1
/
7. 1 Estimación de cost"5
"\ /
7 .2 Preparación del presupuesto ' /
7.3 Control de cost"5 '
de costes

- Faaores ambientales de la - Enunciado del alcance del proyeao - Unea base de coste
empresa - Estructura de desglose del trabajo - il.eqUISltos para la financiación del
- ActNos de los procesos de la - Dlcoonano de la EDT proyecto
organaaoón - Esttmaoones de costes de las - Informes de rendimiento
- Enunciado del alcance del proyecto actJvodades - Infonnaoon sobre el rend1mrento
- Estructura de desglose del craba¡o - lnformaoón de soporte de la del traba¡o
<
z - D1coonano EOT estimación de costes de las actJVÍdades - SohoOJdes de cambio aprobadas
: - Plan de gestión de personal - Sistema de control de camblOS
< • Plan de gestión de costes
o - Registro de nesgas 2. Herramientas y técnicas del coste
~ 2. Herram1enLJ!s y tecnrcas - Suma de costes - AnaltSIS de medroon del rend1mrento
- Esttmac1on por analogoa - Anahsrs de reserva - Proyecoones
- Determrnaoón de indices de costes - Esbrnaoón pararnétr1ca - Revisiones del rendrmrento del
de recursos - Conohación del límrte de la finanoación proyecto
- Estrrnación ascerodente 3. Salrdas - Software de gestion de proyectos
- Esttrnaoón paramétnca - Linea de base de coste - Gestión de vanaoón
- Software de gesnon de proyectos - RequiSltos para la finanoaoón del 3. Salrdas
- Analrsrs de propuestas para proyecto - Estlmaoon de costes (actualrzaoones)
liotaoo~es - Plan de gestión de costes - Linea base de coste (actualtzacrones)
- Anál,51s de reserva (acrualizaoones) - Mediciones del rerodrmrento
- Coste de la calrdad - cambios solrotados - Conclusión proyectada
3. Salidas - Cambios sol10tados
- Estlmaoones de costes de las - Acoones correctivas recomerodadas
actMdades - Activos de los procesos de la
- lnformaoón de respaldo de la organizac:ión (actualtzaciones)
est1rnaoón de costes de las - Plan de gestión del proyecto
actl\IÍdades (actualizaciones)
- CamblOS soltcrtados \..
- Plan de gesbón de costes
(actualtzaCÍOnes)
\. .)
Figura 2. 11: Visión general de la gestión de costos del proyecto.
La Gestión de Costes del proyecto está relacionada co n el coste de los re c u rsos

necesarios p ar a completar las actividades d el proyecto. Sin embargo , la gestión de
costes del proyecto debería considerar también el efecto que tiene la t oma de
decisiones del proyecto sobre los costes de utilizar el producto del proyect o.
Po r ejemplo, la limitación del número de revisiones del diseño puede reduci r los costes
del proyecto, a expensas de un aumento en los costes operativos del c liente. Esta v isión
más global de la gestión de costes del proyecto se sue le llamar cost e del ciclo de vida.

FUNIBER
Este tema es especialmente relev ante en un pro ecto e-Business , pues , por una parte,
1
,
la iniciativa e-Business es un cambio cultural re spe cto de cómo enfrentar la gestión de

un negocio y en có mo plantearse una organiz2c 1ó n de fronteras virtuales y, por otra
parte , la aplicac ión e-Business final es en sí misma la incorporación a una organización
de un tipo de tecno logía en muchas ocasiones nueva, además, de hardware y software
cuya gestión requie re tratamiento especial y de g ran cuidad o , con los costes que ello
significa. Esto s costes involucran, por ejemplo , conseguir profesionales adecuados para
construir la aplicación e-Business y profesionales que luego puedan responder a las
contingencias de la operación de la aplicación e-Business.
Como parte de la gestión del coste:
• En muchas áreas de aplicación, la predicción y análisis del futuro rendimiento

financiero del producto del proyecto se re aliza fuera del proyecto. Cuando se
incluyen estas predicciones y análisis, la Gestión de Costes incluirá procesos
adicionales y numerosas técnicas de dirección general, como la tasa interna de
<
retorno (TIR ), el v alor actual neto (VAN) , período de recuperac ión del capital y z
<
u
otros. "'~
<
• Esta gestión considera las necesidades de información de las entidades ~

<
involucradas en el proyecto: diferentes entidades pueden medir los costes del "'<....
;;;
proyecto de diferentes maneras y en distintos momentos. Por ejemplo , el coste de
"'
~
un artículo de un proveedor puede ser medido cuando se ha autorizado su compra, z
::>
z
cuando se ha pedido, cuando se ha pagado o cuando se ha contabilizado . -o
u
<
o
z
:::>
• En algunos proyectos , especialmente en los mas pequeños , la planificación de ~
"'
""
recursos , la estimación de costes y el presupuesto de costes están tan íntimamente
ligadas que se v en como un solo proceso (por ejemplo , puede desarrollarlas una
sola persona en un período de t iempo relati vamente corto). No obstante el PMBOK
presenta estos procesos separados y distintos porque las herramientas y técnicas
para cada uno son diferentes.
e.- Gestión de la calidad

La Gestión de la Cal idad del proyecto incluye los procesos necesarios para asegurar que
el proyecto satisfará las necesidades para las que se ha llevado a cabo. Implementa un
sistema de administración de la calidad a través de políticas, procedim ientos y procesos
de planificación de calidad, aseguramiento de calidad y control de calidad, junto con
actividades contin uas de mejoramiento de procesos llevadas a cabo mientras sean
ne ce sarias. La pro ve e una vista g eneral de los siguientes procesos
principales de gestión de la calidad del proyecto :

FUNIBER ~ a .. . .11m1mm. . . . . . ..._.............r.-. . . . . . . . . . . .
GE STIÓN DE PROY ECTOS
GESTIÓN DE LA CAUDAD
DEL PROYECTO 1
1
1 1 1
r r 8.2 Realizar 11Se9uramiento r
8.3 Realizar control de calidad '
8.J. Planificaáón de la calidad de calidad
1. Entradas l. Entradas !. Entradas
- Factores ambientales de la - Plan de gestión de calidad - Plan de gestión de calidad
empresa - Métricas de cahdad - Métncas de calidad
- Activos de los procesos de la - Plan de mejoras del proceso - Listas de control de cahdad
organizaoón - lnformaoón sobre el rendimiento del - Actrvos de los procesos de la
- Enunoado del alcance del proyecto traba¡o organizaoón
- Plan de gestión del proyecto - Soliotudes de cambio aprobadas - Información sobre el rend1m1ento del
2. Herramientas y tecrncas - Mechciones de control de calidad traba¡o
• Anáhs1s coste-benefioo - Sohatudes de cambio 1mplementaGas - Solicitudes de cambio aprobadas
- Estudios comparabvos - Acoones correctivas implementadas - Productos entregables
· Diseño de expenmenros - Reparaoón de defeaos implementada 2. Herramientas y tecn1cas
- Coste de la calidad (COQ) - Amones prevenbvas 1mplemt!ntadas - D;agrama de causa y efecto
· Herra,,1entas adicionales de 2. He'.T'am1entas y recmcas - o.agramas de control
planificación de calidad - Herramientas y técnicas para la - Diagramas de íluJO
3. Salidas plan1ficaoon de cahdad - Histograma
- Plan de gestión de calidad - Aud:torias de cahdad - O.agrama de Pareto
- Metncas de calidad - AnahSls del proceso - Diagrama de comportamiento
- Listas de control de calidad - Herramientas y técnicas para el - Diagrama de dispersión
- Plan de me¡oras del proceso control de cahdad - Muestreo estadisnco
- Linea base de calidad 3. Sahdas - lnspecoón
- Plan de gest>on del proyecto - Cambios soliotados - Revisión de reparaoón de defectos
(actualizaciones) - Amones correctivas recomendadas 3. Sahdas
'- .)
- Acbvos de los procesos de la - Med1oones de control de calidad
<
z organl2il0Ón ( acbJahzaoones) • Reparaaón de defeaos validada
: '- .)
< • Acoones preventivas recomendadas

o
- Cambios sohatados
~ - Reparaaón de defectos recomendada
- Acovos de los procesos de la organización
(acrualízaoones)
- Productos entregables validados
• Plan de gesnón del proyecto
(actuahzaaones)
'"
Figura 2.12: Visión general de la gestión de la calidad del proyecto.
El método básico de gestión de calidad a seguir debe ser compat i ble con el de la
Organización Internacional de Normalización (ISO por sus siglas en ing lés). Este enfoque
generalizado t ambién debería ser compatible con métodos de gestión de la calidad
vi nculados a Deming , J uran , Crosby y otros, y otros como la Gestión de la Calidad Total
(TQM - Total Oua/ity Management), Six Sigma , Cost e d e Cal idad (COQ - Cost o f
Oua/ity) o la Mejora Continua.
La Gest ión de la Calidad debe dirigirse tanto a la d irección de l proyecto como al

produ cto del proyecto . Un fa llo en el cumpl imiento de las exigencias de la calidad en
alguna dimensión puede tener consecuencias negativas serias para alguna o todas las
entidades involucradas en el proyecto. Por ejemplo:
• Cumpl ir los requerimientos del cliente mediante un trabajo excesivo del equipo del
proyecto puede producir consecuencias negati v as co m o u n incremento en la
rotación de personal, errores o doble trabajo.
DIRECCIÓN Y GESTIÓN DE PROY ECTOS T IC 49

FUNIBER
• Cumplir los objetivos de prog ramación del proyecto , acelerando las revisiones de la
calidad planificadas, puede produci r consecuencias negativas cuando existan
errores que no sea n det ectados.
Un aspect o c rítico de l a Gestión d e la Calidad en el contexto del proyecto es la

n ecesida d de conve rtir los necesidades, deseos y expectativas implícitos en
necesidades evidentes reque rimientos, a t ravés de la Gestión del Alcance del proyecto.
El equipo de dirección del proyecto debe tener cuidado de no confundir calidad con
grado. Grado es una categoría o rango dado a entidades que, ten ie ndo el mismo uso
funcional, tienen diferentes reque rimientos de calidad. La baja ca li dad es siempre un
problema; el bajo grado puede no serlo. De igual manera, se puede hacer la misma
comparación entre precisión y exactitud. Unas medic i ones precisas no son
necesariamente exactas.
Dete rminar y conseguir los niveles adecua dos de calidad y grado, y de prec1s1on y
exactitud, son las responsabilidades del gesto r del proyecto y del equipo de dirección
del proyecto.
El equipo de di rección de l proyecto debe saber también que la gestión de la calidad

moderna complementa a la dirección de proyectos moderna. Por ejemplo, ambas ..
<
<
disciplinas reconocen la importancia de: 5

~
z
=>
z
-o
• La satisfacción del cliente : entender, evaluar, definir y administrar las expectativas V
<
e
del cliente, con el fin de cumpli r con su s requerimientos. z
::>
u.
• La prevención sobre la inspección : el coste de evitar los errores siempre es mucho

menor que el de corregir los.
• Responsabilidad de la gestión : el éxito requiere la participación de todos los

miembros del equipo, pero pe r manece la r esponsabilidad de l a dirección de
suministrar los recursos necesarios para lograrlo.
• Mejora Continua : el ciclo reiterativo planificar-ejecutar-comprobar-actuar es la base

para la mejora de la calidad. Además, las iniciativas de mejora de la calidad llevadas
a cabo por la organización ejecutora (por ejemplo , TQM y Six Sigma) , pueden y
deben mejorar la calidad de la dirección del proyecto , así como la calidad del
producto del proyecto. Modelos de mejora de procesos incluyen a Malcolm
Baldrige, CMM y CMMI.
Sin embargo, hay una diferencia impo rtante sobre la que el equipo de dirección del
proyecto debe estar muy precavido: la naturaleza temporal de los proyectos implica que
las inversiones en mejo ra de la calidad del producto , especialmente la prevención de
so DIR ECCIÓN Y GESTIÓN DE PROYECTOS TIC

GE STI ÓN DE PROY ECTOS
defectos y las pruebas, deben frecuentemente sopo rt arse por parte de la organización
ejecutora dado que el proyecto puede no durar lo suficiente para re coger la recompensa.
f.- Gestión de recursos humanos
La Gestión de Recursos Hum anos del proyecto incluye los procesos necesarios (ver
) para organiz ar y administrar el equipo de proyecto, el que comp rende al
personal a quien ha sido asignado algún rol o responsabilidad para completar el
proyecto. Los miembros del equipo deben estar involucrados en muchas de las
planificaciones del proyecto y de la toma de decisiones. Esto añade habilidades durante
el proceso de planificación , y genera un mayor compromiso para con el proyecto. Es
usual referirse a los miembros del equipo de proyecto como el "staff" del proyecto. El
número y tipo de miembros puede alterarse durante el desarrollo del proyecto.
Hay gran cantidad de literatura sobre las relaciones interpersonales en un contexto

operativo continuo. Algunas de las muchas ideas extendidas son:
• Liderazgo, comunicación, negociación y otras más aptitudes clave en la dirección

genera l.
< • Delegación, motivación, enseñanza, apadrinamiento y otros temas relacionados

"'<
¡...
con el trato personal.
"'~
~
3 • Creación de equipos, resolución de conflictos y otros temas relacionados con el
.a
V
<
trato en grupo.
o
....5 • Análisis del grado de preparación., reclutamiento, retención, relaciones laborales,
seguridad e higiene en el trabajo y otros elementos relacionados con la función de
administración de recursos humanos.
La mayor parte de este material es aplicab le al liderazgo y a la dirección de personas en

proyectos y el gestor del proyecto y el equipo de dirección del proyecto deben estar
familiarizados con estos conceptos. Sin embargo , deben ser también sensibles a la
aplicación de estos conceptos en el proyecto. Por ejemplo:
• La naturaleza temporal de los proyectos supone que las relaciones personales y de

la organización serán, generalmente, temporales y nuevas. El equipo de dirección
del proyecto debe tener cuidado a la hora de seleccionar técnicas que sean
apropiadas para estas relaciones temporales.
• La naturaleza y el número de entidades involucradas en el proyecto cambiarán a

menudo según el proyecto va pasando por las distintas fases de su cielo de vida.
Como consecuencia de esto, técnicas que son aptas en una fase determinada ,
pueden no ser efectivas en otra fase. El equipo de dirección del proyecto debe
DIRECCIÓN Y GESTIÓN DE PROYECT OS TI C 51

GE STIÓ N DE PROYECTOS
FUNIBER
pr esta r especial atenc ión en uti lizar las t écnicas apropiadas a las necesidades
actuales del proyecto.
• Las act ividades administrat iv as de los re c ursos humanos son ra ra v ez una

responsabilidad directa del equipo de direcc ión del proyecto. Sin embargo , el equipo
debe conocer suficientemente los requerim ientos administrativ os para asegura r su
cumplimiento.
GESTIÓN DE LOS RECURSOS

HUMANOS DEL PROYECTO
1 1
/ 9.1 Planificación de los

recursos h umanos "' / 9 .2 Adquirir el equipo del proyecto "\
l. Entradas l. Entradas
- Factores ambientales de la - Factores ambientales de la empresa
empresa - Activos de los procesos de 1a
- Activos de los procesos de la organizaoón
orgamzac1on - Roles y responsabilidades
- Plan de gestion del proyecto - Organigramas del proyecto
-
<
- Plan de gestion de personal z
- Requisitos de recursos de las <
actMdades 2. Herramientas y tecn1cas
2. Herramientas y tecnicas - Asignación previa
- Organigramas y desmpoones - Negooac1ón
de cargos - Adqu1s1oón
- Creaaón de conexiones - Equipos virtuales
- Teoría de la organización 3. Salidas
3. Salidas - Asignaciones del personal del proyecto
- Roles y responsabilidades - Dtsponib1hdad de recursos
- Organigramas del proyecto - Plan de gestion de personal
- Plan de gestión de personal (actualizaciones)
'-
~
/ 9.3 Desarro llar el equ ipo del
proyecto
'I
/ 9 .4 Gestionar el equipo d e l p royecto ' o
5
u.
l. Entradas l. Entradas
- Asignaciones del personal del - Activos de los procesos de la organizaoón
proyecto - Asignaoones del personal del proyecto
- Plan de gestión de personal - Roles y responsabihdades
- Disponibilidad de recursos - Organigramas del proyecto
2. Herramientas y tecnicas - Plan de gestión del personal
- Habilidades de gestJón generales - Evaluación del rendimiento del equipo
- - Formacion
- Act1V1dades de formac1on de equipos
~ - lnformaoón sobre el rendimiento del
traba¡o
- Reglas bas1cas - I nformes de rend1m1ento
- Reub1caoon 2. Herramientas y técnicas
- Reconoomiento y recompensas - Observación y conversación
3. Salidas - Evaluaoones del rendimient o del
- Eva1uac1on del rendimiento del proyecto
equipo .) - Gesoón de confltctos
\..
- Registro de po1em1cas
3. Salidas
- cambios sohc1tados
- Acciones correctivas recomendadas
- Acciones preventivas recomendadas
- Activos de los procesos de la organizaaón
(actualtzaaones)
- Plan de gestión del proyecto
'- (actualizaoones)
Figura 2.13: Visión general de la Gestión de los Recursos Humanos del Proyecto.

FUNIBERf~
GESTI ÓN DE PRO YECTOS
c;::¡;¡:w:¡;;:jM¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡:¡m_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _
La Gestión de Recursos Humanos del proyecto interactúa con otros procesos . Sin
embargo, existen algunas interacciones que requieren una planificación adicional, por
ejemplo:
• Luego de crear el WBS, puede ser necesaria la contratación de miembros

adicionales.
• Los nuevos miembros poseen un nivel de experiencia que afectará al riesgo del
proyecto, por consiguiente, será necesario replanificar la gestión de riesgo.
• Cuando la duración de las actividades son estimadas antes de que se conozcan a

todos los miembros del equipo, las competencias adquiridas por los mismos puede
causar cambios en la duración o calendarización de las actividades.
g.- Gestión de las comun icaciones
La Gestión de Comunicaciones del proyecto comprende los procesos necesarios para ,

<
z en el momento y manera adecuados, asegu rar la elaboración, recopilación , distribución,
<
~ archivo y disposición definitiva de la información del proyecto. Proporciona las
~
:!:
< conexiones clave entre personas, ideas e información , que son necesarias para el éxito
o
~ del proyecto. Esto se hace para que cualquier persona implicada en el proyecto deba
::« comprender cómo las comunicaciones que se realiz an entre personas afectan al
<
proyecto en su conjunto. La provee una vista general de los siguientes
~
~
> procesos generales:
z
::>
5 Las habilidades comunicacionales están relacionadas a las comunicaciones de la gestión
u
<
o
z
:::> del proyecto , pero no son lo mismo. El arte de la Comunicación es un tema extenso y
u..
a comprende una gran cantidad de aspectos. Por ejemplo:
• Modelos emisor-receptor (lazos de realimentación, obstáculos a las

comunicaciones, etc.).
• Elección del medio (cuándo comunicar por escrito y cuándo hacerlo verbalmente ,
cuándo escribir un memorando informal y cuando hacer un informe formal , etc.).
• Estilo de escritura (voz activa frente a voz pasiva, estructura de las oraciones,
elección de vocabulario, etc.).
• Técnicas de presentación (lenguaje del cuerpo, diseño de ayudas visuales , etc.) .
• Técnicas de dirección de reuniones (preparación de una agenda, tratamiento de

conflictos, etc.).
Esta área es de importancia ya que muchos proyectos fallan por problemas de

comunicación. Por esta razón , es responsabilidad del gestor de proyectos crear un

FUNIBER Í~
ambiente dentro del proyecto prop1c10 para una efectiva comun icación intra e inter-
grupal que permita que todas las pa rtes estén informadas de manera fluida.
Lo importante es no dar sorpresas , menos al cliente. Por esto , las comunicaciones no

deben depender de informes aislados , sino que es bueno aprovechar las reuniones para
comunicar. No hay que olvidar que una bue na frase puede ser mejo r que un cuidado
info rme de estado.
1COMUNICACIONES
GESTIÓN DE LAS
DEL PROYECTO
'1
/
..., / ...,
10.1 Planificación de las
10.2 Distribución de la información
comunicaciones
l. Entradas 1. Entradas
- Factores ambientales de la - Plan de gestión de las comunicaaones
empresa 2 Herram1em:as y técnicas
- Activos de los procesos de la • Habihdades de comunicaoon
orgaruzación - Sistemas de recop11aoon y recuperaaón
<
---
- Enu"lcado del alcance del proyecto de información z
<
,___ - Plan de gestión del proyecto - Métodos de d1stribuoón de la 1;-ifonnaoón ~
- Restricciones 3. Salidas "'
:¡:
• AsunCJones - Activos de los procesos de la <
o
2. Herramientas y técnicas orgarnzaoón (actuahzac1ones) "'w
- Anahs1s de requisitos de • cambios solicitados "'
comumcaaones 
\..
/
"'
'
/ ...,
-~
ü
<
o
1 0.3 Informar el rendimiento 10.4 Gestionar a los interesados
":>
u.
1. Entradas l. Entradas
- lnformaoon sobre el rendimiento - Plan de gestión de las comunicaaones
del traba¡o - Activos de los procesos de la orgarnzaoón
- Mediciones del rendimiento 2. Herramientas y tecn1cas
- Conclusión proyect:ada - Métodos de comunicación
- Mediciones de control de calidad • Registros de polemicas
• Pian de gestión del P'O\'ecto 3. Salidas
- Linea base para le medioón del - Polémicas resueltas
- rendimiento
~
- Soharudes de cambio aprobadas

- Solicitudes de cambio aprobadas - Acaones correctuas aprobadas
• Productos entregables • Activos de los procesos de la organización
2. Herramientas y técnicas (actualizaaones)
• Herramientas de presentaaón de - Plan de gesbon del proyecto
información (actuahzaaones)
- Reco;>·lac1ón y comp1:aaón oe la
información sobre el rend.miento
• Reuniones de rev1s1ó'1 del estado
' /
de la situación
· Sistemas de informe de oempo
• S:stemas de informe de costes
3. Salidas
- Informes de rendimiento
- ProyeccJOnes
• camo1os sohatados
• Acoones correctivas recomendadas
• Ac:bvos de los procesos de la
organización (actualizaciones)
'- J
Figura 2 .14: Visión general de la gestión de las comunicaciones del proyecto.

GE STI ÓN DE PROY ECTO S
h.- Gestión del riesgo
El riesgo es un evento o condición incierta que, si ocurre, tiene un efecto positivo o

negativo en por lo menos un objetivo del proyecto , tal como tiempo, costo , alcance o
calidad . Un riesgo puede tener una o más causas y, si ocurre, uno o más impactos.
La gestión de riesgos de l proyecto inc l uye varios procesos cuyo fin último es la
eliminación del riesgo o la disminución de su presencia e impacto. El objetivo de la
gestión de riesgo s es el de maximizar la probabilidad e impacto de eventos positivos, y
de minimizar las consecuencias de los eventos negativos al proyecto.
La gestión de riesgos, en muchos casos definida como func ión , es una de las más
impo rtantes hoy en día debido al entorno cambiante en que se desenvuelven los
proyectos tecnológicos en particula r, y cualquier proyecto en general.
En general los procesos de gestión de riesgos va rían , pero suelen centrarse en los
siguientes aspectos que en suma son fases o procesos:
• Identificación y cuantificación cuyo fin a analizar y evaluar los riesgos .
• Generación de respuestas cuyo fin es planificar y elaborar respuestas o acciones de

mitigación de riesgos .
• Ejecución y control de las respuestas ante el riesgo cuyo fin es que los riesgos sean
gestionados durante la ejecución de un proyecto y no esperar a que ocurran o a
gestionar las consecuencias de los riesgos .
A continuación se dan algunas ideas de lo que incluye y se real iza en estas fases.
• La fase de identificación y cuantificación permite v alorizar los riesgos y elegir

un enfoque adecu ado para gestionar el proyecto. Esta valorización incluye :
identificar riesgos y cuyo fin es desarrol lar una lista de los r iesgos que
pueden afectar el proyecto y su producto;
analizar los riesgos que consiste en valo r iza r la exposición al riesgo y la

probabilidad e impacto de cada uno de ellos ; y ,
priorizar los riesgos con el fin de produ ci r una lista de ri esgos priorizados
segú n el impacto que un riesgo tiene en el proyecto y en el producto.
• Durante la fase de genera ció n de respuestas deben planificarse y elabo rar se

respuestas . En la planificación, el gestor de proyecto necesita realizar una
valoración rea lista de riesgos y desarro llar un plan para contro la rles en base a
factores como el tamaño del proyecto , l a estructura del proyecto y l a
experiencia con la tecnología. En la elaboración de respuestas es impo rtante
co n si derar que los r iesgo s asociados a los factores conside rad os en la
DI RECCIÓN Y GEST IÓN D E PROYECTOS TIC SS

GESTIÓN DE PROYE CTOS
FUNIBER ff
planificación aumentan conforme el proyecto crece, es poco estructu ra d o (es

deci r, los re qu erimientos no se definen bien y probablement e cam b ien d urante
el pro yecto) y h ay me n os experien cia de l equipo en la tecnología a usa r.
• Durant e la fase de Ejecución y Control , suele adoptarse un enfoque de

conti n genc ia como estr ategia adecuada de gestión de los diverso s t ipos de
riesgo , pa ra las cuales exist en diversos tipos de h erramie n tas de integración
ext ern a, inte rn a y de con trol y planificación. Esto defin e un mapa de escen arios
y al m ismo tiempo posibilidades t al como muestra la
Tamaño Planificación formal

y control de herramientas
<
z
<
u
"'-
;¡;
Estructura Tecnología <

o
~
Herramientas de Herramientas de
integración externa integración interna
Figura 2.15: Enfoque de contingencia de gestión de riesgo.
Las fases , ayudan a valorizar los riesgos . Esto permite y ay uda a planificar según los
riesgos de may or impacto e incidencia , p lanteando planes de contingencia para hacerles
frente y moni t orearles. Es importante que los riesgos sean valor izados continuamente
cuando se mon itorean p ara mantener actualizada u na l ista de, po r ejemp lo , los 1 O
rie sgos de mayor prioridad e incidencia.
La gestión de riesgos, a t rav és de sus fases perm ite organizar v arias est rategias según ,
por ejemplo , el t amaño del proyecto . Por ejemplo , tal como se describe a continuación.
• Pro yectos con una estructura pequeña se pueden beneficiar de herramientas de

integración externa para crear relaciones efectiv as entre el equipo del proyecto
y los clientes de la o rganización. Por ejemplo:
selecc ionar al gestor del proyecto y a los miembros del equ ipo del proyecto
desde la misma organizac ión que recibirá el producto;
mantener un a represent ación de clientes en t odas, o casi todas , las
reunio nes de revisión del proyecto; y /o ,

mantener una amplia difusión y distribución de los informes de estado del

proyecto dentro de la organización.
• Proyectos que involucran el uso de nueva tecnología deberían confiar más en
herramientas de integración interna, las cuales han sido diseñadas para mejorar
la competencia y operación técnica del equipo como una unidad integrada . Por
ejemplo:
seleccionar o disponer de miembros experimentados;
contar con un gestor del proyecto con gran dominio técnico y experiencia
probada en gestión de proyectos;
mantener frecuentes reuniones de estado del proyecto con los miembros.
• Grandes proyectos , con una gran estructura deberían ser gestionados con
profusión de herramientas de gestión y de cont rol. Estas herramientas ,
representan un esfuerzo sistemático y disciplinado de planificación y control.
Por ejemplo, WBS , presupuestos, planes y procedimientos de seguimiento.
A continuación la forma como el PMBOK organiza la gestión de proyectos. La

<
z
< muestra los procesos que se consideran .
":!'.
~
<
oa:
w
• Planificación de la gestió n de riesgos : en el cual se decide, co mo enfocar, planificar
"'
< y ejecutar las actividades de gestión de riesgos para un proyecto.
a:
<
• Identificación de riesgos: permite determinar qué riesgos pueden afectar al

proyecto y document ar sus características.
• Anális is cualitativo de riesgos : cada riesgo se clasifica según su probabilidad de

ocurrencia e impacto, para realizar otros análisis o acciones posteriores.
• Análisis cuantitativo de riesgo s: cada riesgo identificado en los objeti vos generales
del proyecto es ana lizado según su efecto .
• Plan ific ación de la re sp ue st a a los riesgos: se desarrollan opciones y acciones para

mejorar las oportunidades y reduc ir las amenazas a los objetivos del proyecto.
• Seguimiento y co ntrol de riesgos : una vez identificados los riesgos del proyecto , es
necesa r io realizar un seguimiento a éstos, además de supervisar los riesgos
residuales, identificar nuevos riesgos, ejecutar planes de respuesta a los riesg os y
evaluar su efectividad a lo largo del ciclo de vida del proyecto .

1
GESTIÓN DE LOS RIESGOS
DEL PROYECTO l
/
11.1 Pl•nlfiCildón de la gestión
de riesgos ' 11. 2 Identificación de nesgos
"\
11.3 Análisis cualitativo de ñesgos
l. Entra~as l. Er.tradas l. Entradas

- Factores a'T't>entales de la - Facto·es amb<en:ales de la empresa • Actrvos de los procesos de la
empresa • A..--:i-JOs de los p'OCesos de la organ1zac1on
• Acttvos de los procesos d¿ IJ organizaoón • Enunciado del ak:ance del proyecto
organización • Enunoado del alcance del proyecto • Plan de gestión de óesgOs
• Enunoado del alcance de p-o • ..-.~c • P'.an de ges~ón d~ nesgcs • Registro de riesgos
• Plan de gest•on de: p•oyec: • Plan de g~ón del proyecto 2. Herramientas~ témtc::as
2. Herramientas y ternicas
- 2 Herraf'""!1entas y teauc:as • Evaluaoón de p•obab•lidad e impacto
• Reurnones 1·
3. Salidas
ª""'
• Plan de gestion de nesgos l-
s s de p:.,~ '1::a: ~- 1 - Revis.o;,es de docurnt:ntac•of'l
Tecni<as de reco;:>ilitción de
1nformaaón
• Anal<SJs de listas de control
• A:·1a1:ss de asunciones
- de nesgas
• Matr.z de probab11'dad e impacto
• Eva uaocn de la caMad de los datos
sobrer~os
- Co~e9CJ"":!llOÓn de nesgas
• Tecnteas de d.a;¡ramación • Evaluaoón oe la urgenc•• del nesl}O
Salidas 3. S;,i1<las
• Reg stro de riesgos • Reg•stro de riesgos (actualizaciones~
\. \.. ~
r
11.4 Análisis cuantitativo de ñ esgos' "
/ 11.6 Seguimiento y control
11.S Planificación de la respuesta "
a los ñesgos de nesgos
l Entradas l. Entradas l . Entradas
• Acllvos de los procesos de :a • P'.an de gestión de nesgos - Plan de ges'.ión de nesgos
<
organwtoon 1 • Registro de nesgos • Reg!StrO de riesgos z
<:
• Enunoado del alcance oel proyecto 2. Henamte11tas y tecmcas • Sohotudes de cambio aprobadas u
- Plan de gestión de nesgos • Estrategias pa'll nesgos negauvos • Información sobre el renchm•ento del :;¡
• Plan oe 9est1on del aon!>gra-r.a de o amenazas traba¡o :i:
<
proy.,.;to • Estrategias oara rie5905 posiovos • Informes de rendimiento o
~
• Poan de gest1on de los costes éel - u oporrun1dades 2. Herramientas y técnicas ~

proyecto
2. Herramienta.) y tecnteas
• Estrategia comun ante amenaza• y
opo<tUmdades - • Reevaluaoon de los nesgas
• Auditoria de tos riesgos :::o:
·Técnicas de ret:0?1,aci:>n ~ - Estrategia de respuesta para • Anál1s·s d~ vanaoón v d.? tendenoas <
,...
rep•esentaoon de datos conongenoas - Mectioón del rend 1tr11ento téauco :;;
- Técmca.s de a~.IS!s cua'lt::atwc oe 3 Salidas · Aná. s·s d~ reserva "'u
nesgas y de noóe a~o · Registro de nesgas (aa..ial1zaoones) • re.imones sc~•e el es:ado de la ::z
3. Sahdas • Plan oe gestión del pro1ecto s tuao011 ::>
• Regtstro de nesgcs {actual1zaoooes) 3. Salidas z
-o
'-.
(actuarizaoones)
~
• Acuerdos contractuales relaoonados • Reg!Stro oe riesgos (acruahzadones) u
• (amboos sol•C•cados <:
con el nesgo
.r"
\. _/ • Acciones correctl\fils recomenéadas z
• Acciones preventivas recomendadas
· ActNos de los procesos de la
organizaoón (actual:zaoones)
• Plan de gestión del proyeao
(actuahzaoones)
~
'
Figura 2.1 6 : Visión general de la gestión de riesgos del proyecto.
i.- Gestión del abastecimiento
La Gestión del Abastecimiento del proyecto incluye los procesos requeridos (ver
) para la adquisición de bienes y servicios, o resultados requeridos del exterior del
equipo del proyecto , para poder ejecutar el trabajo asignado. Existen dos perspectivas
para definir el abastecimiento. La organización puede ser compradora o pro veedo ra del
producto , servicio o resultado definido bajo un contrato .
58 DIRECCIÓN Y GESTION DE PROYECTOS TIC

GE STI ÓN DE PROYECTOS
La gestión del abastecimiento incluye la administración del contrato y los procesos de

control de cambios requeridos para administrar los contratos u órdenes de compra
emitidas por miembros autor izados del equipo de proyecto .
T ambién incluye la administración de cualquier contrato emitido por una organización

externa (e l comprador) que está adqui riendo el pro yecto de una organización ejecutora
(e l vendedo r ), y la administración de las obl igaciones contractuales definidas en el
contrato.
El proveedor dirigirá normalmente su trabajo como un proyecto. En tales casos:
• El comprador se convie rte en cliente y es así, una entidad del proyecto clave para el
proveedor.
• El equipo de dirección de proyectos del proveedor debe estar interesado en todos

los procesos de dirección de proyect os, no sólo en aquel los de esta área de
conocimiento.
<
¡:
..
<
<..>
~
• Los términos y condiciones del contrato se convierten en un dato clave para
<
o
"'w
muchos de los procesos del proveedor. El contrato puede contener realmente los
"' datos (por ejemp lo, ent regas principales, hitos clave , objetivos de coste) o puede
..
:!
....< limitar las opciones del equipo del proyecto (por ejemplo , en los proyectos de
v;
~
> diseño se requ iere frecuentemente la aprobación del comprador de las decisiones
:5 de asignación de personal) .
5
<..>
<
o
¡:
"'
LI..
='
DIRECCIÓN Y GESTION DE PROYECTOS T IC 59

FUNIBER f~f
GESTIÓN DE PROY ECTOS
1GESTIÓN DE LAS AOQUISrCIONES 1

DEL PROYECTO
..... ..,
12.1 Planificar las compns y
adquisiciones
/
12.2 Planificar la contratación ' / 12.3 Solicitar respuestas de
vendedores
l. Entradas 1. Entradas l. Entraaas

- Faaores ambtentaies de la - Plan de gest1on ae las adQuiS1oones - ktlvos de los procesos de la
empresa • Enunoado del traba¡o del contrato orgamzaoón
- Activos de los procesos de la - Deos1ones de fabncación d.reaa - Plan de gest1on de las adquisioones
orgamzaoón ocomora • Documentos de la adqu1sioón
- Enunoado del alcance del proyec:o - Plan de gestJOn ael proyeco 2- He~rmen:as ) tkn1c.as
• Estruaura de desg;ose del tra:ia¡o • Regrs:ro ae "esgos - co~'t:r'!:ioas oc cfe~t:n:es
• Olcoonano de la EDT - Acuerdos contraC1ua1es r.,.aoonados • P.\J~i1C1dad
- • Plan de gesuon del proyecto - con el nesgo >---- - Desarrol.ar una hsta de vendedores
calificados
• Registro de nesgos - Requ•s1tos oe rl'::U'50S
• Acuerdos comraauales relacionados • Cronogra"T'a ael proyecto 3. Salidas
con el nesgo • Esti.~ de co..:es de tas -us:a de vendedores ca '1cados
- ReQulsltos de •eru.,;os ac.ivodalles - PaQuete de oocumentos de la
Crcnograma de P-O\'CC'J - Linea DaS'! de cos:e aOOU'S•OOl'l
F•tmac sae CCY. ' ,d IJS 2. Herrd"1 tas f tea" ca> P·: p f'S-. as
\.. ./
ac;t1v1dades • Formularios estandar
- Linea base de coste - Ju10o de e<per'.os
2. Herra.,, entas y tec~icas 3 So:1aas
- Ana .s•s de fabncaoon direaa o - Documentos de la aóq'.JISIOO<l
com;ira • Cntenos de e-.<1luaoon
- JUICIO de l!Xl>l!'ICS - Enuooado del trabaJO del contrato
• Tipos de contratos (actuahzaoones)
3. Salidas \.. ~
• Plan de gesbÓn de las adqulSIOOnes

- Enu'.'IOado del traba.JO del contrato
• Deasaones de fabncaoóo d rec:a o
compra
'- • Cambios solicruidos ,/
/ ..., É
12-4 Selección de vendedores 12.S AdmmistnK:l6n del contrato 12.6 Cierre del contrato
1. Entradas l. Entradas !. Eitradas

- ActrJos de los procesos de la - Contrato • Plan de gestión de la adqu1sioones
0<9anizaoón • Plan de gestJ6o del contrato ~
- Plan de gestión de 1contrato
- Plan de gestión de las adquisioones - Vendedores selecoonados • Documentación del contrato
- Cntenos de evaluaoón - hformes de rendlm.ento • P'l>Celimiento de aer.e del contrato
- Paquete de clocuinentos de la
• Solimudes de caT1blo aprobadas 2. He:--ramier.:.as y tecn1c.as
aóQu·sioón • Infonnaaon sobr~ el rend1m1en~o • Aud1tonas de adq:.iSIOÓri
• Propuestas - Sistema de gest1on de registros
de traba)O
• !Jsta de vendedores calificados 2. Herram1en:as y técnicas 3. Solidas
- Plan de gestión del proyecto • S1stt!ma de control de cambios del • Contra:os comple2dos
• Regtsuo de n~ contrato - ktr.-os de los procesos de la
• Acuerdos contract.Ja es relaa<>-.ados • Rev15'Ón de1 rend mento rea'1zada organ1zaoon (actualizaciones)
con el 0e590
- 2. Herram·entas y tK11icas ~
por el compra~or
• lnspecoones y auditorias
- S1s:ema ce ponderaaC1n • Informar el rend1m1ento
• Estimaoones 1ndepe.,d1entes • S•stema de pago
• S.ste'lla de selecc1on • Admims:raaon ae redamaoones
- Negooaoóo del coitra;o • S s!e:na de ges-JCin de ce:¡ S-JO
- S.S',emas de ca •.caoon de - TecnoiOg:a c:e :a :iformaoo:i
vendedores 1
3 Sof1das
• Ju1c10 d~ expenos - Documen:aaon del contrato
- Tecmcas de evaluaaon de propuestas • Cambios sohc.:aóos
3. Sabdas • Acoones CXITTl!C',1vas recomendadas
- Vendedores seleccionados • AaM>s de kX procesos de la
• Cont'ilto organaaoón (a'1'Ja IZilOOneS)
- Plan de gest>óo Oel contrato • Plan de gestoórl del proyeao
- O.spon1bilidad de fl!CUrsos (actuaf1Zaoones)
- Plan de gesbon O<: las • Plan de gestJón de las adqu1s•c1Cnes
adqu1SKJ0'1CS (actJ2Jl1:aaones) • Plan de gesuón de! contrato
• CamblOS soliotados ,) \... .)
Figura 2. 17: Visión general de la gest ión de abastecimiento del proyecto.
60 D IRECCIÓN Y GESTIÓN DE PROYECTOS TIC

2.3.2 PROCESOS DE GESTIÓN DE PROYECTOS
Los Procesos de Gestión de Proyectos son el eje de toda la propuesta del PMBOK (
), constituyendo el centro de las mejores prácticas de gestión de proyectos. En la
codificación X. Y de cada proceso, la X indica el número de área de conocimiento a la
cual pertenece , mientras la Y es un co rrelativo.
A cada proceso se le asocian entradas y salidas y un conjunto de herramientas y

técnicas de gestión. Esta representación de la gestión de proyectos, ha sido una de las
principales aportaciones del PMBOK al mundo de la investigación y de la profesión de
proyectos, al mostrar de manera clara que existen , p or una parte, procesos de gestión
y, por otra parte, herramientas y técnicas donde, los primeros us an las segundas a
conveniencia según necesidades y habilidades del gestor y de los participantes .
Los procesos de gestión de proyectos son presentados como elementos que contienen
interfases def inidas. Sin embargo , en la práctica los procesos interactúan de diferentes
maneras, lo que nos lleva a reconocer que hay más de una manera de administrar un
proyecto. La aplicación de estos procesos a un proyecto es iterativa y muchos de los
procesos son repetidos y revisados durante el proyecto .
Un concepto importa nte para definir la interacción entre los procesos de gestión de
proyectos es el ciclo de plan-do-check-act (planificar-hacer-chequea r-actuar). En donde
el resultado de una parte del ciclo se convierte en la entrada de la sigu iente parte. El
ciclo se muestra en la
Hacer
Actuar
Figura 2.18: Ciclo plan-do-check-ad.

FUNIBERÍ~
El ciclo mencionado anteriormente es muy sencil lo para definir la naturaleza integradora

de los grupos de procesos , sin embargo puede aplicarse a las interrelacio nes entre los
grupos, de forma extendida, como muestra la
Proceso de
seguimiento y control
Proceso de
rz
<
z
<
....
"'
Figura 2.19: Ciclo plan-do-check-act aplicado a grupos de procesos.
"J .. • :.-.... ... __.,, ;....:..., , ,, •••

-~-
---· 1 •· ~·¡ :,._ '"""' ).""
~
·~ :.;.J.."": .i• 1 • • ' 11
-·
Gestión de la Integración
Desarrollo del cuadro de proyecto (p Desarrollar un plan de proyecto que autorice formalmente al proyecto o una fase del
4.1
charter) proyecto.
Desarrollo de alcance de proyecto
4.2 Desarrollar el alcance del proyecto en una narraova de alto nivel.
preliminar
4.3 Desarrollo del plan de gestión de Documentar las acciones necesarias para definir, preparar, integrar y coordinar todos los
proyecto planes subsidiarios en un plan de gestión de proyecto.
Dirección y Gestión de la e¡ecuc1ón del
4.4 Ejecutar las tareas definidas en el plan de gestión de proyecto.
proyecto
Monitoreo y control de rareas del Controlar los procesos usados para iniciar, planificar, e¡ecutar y cerrar el proyecto de
4.5
proyecto manera que coincidan con los ob¡etivos descritos en el plan.
4.6 Control de cambios Integrado Revisar todos los cambios solicitados, aprobados y realizados.
Finalizar las actividades de todos los grupos de proceso, para cerrar formalmente el
4.7 Cierre del proyecto
proyecto o la fase de proyecto.
Gestión del Alcance
Desarrollar un plan de gestión del alcance que indique cómo será definido, verificado y
5.1 Planificación del alcance controlado, y cómo será creada la WBS.
Desarrollar un informe escrito del alcance que sirva de base para las futuras deos1ones del
5.2 Definición del alcance proyecto.
5.3 Creación de un WBS (Work Breakdown Subchvidir las principales entregas del proyecto en componentes más pequeños y
Structure) mane¡ables.
5.4 Verificación del alcance Aceptar formalmente que los entregables del proyecto han sido completados.
5.5 Control del Alcance Controlar los cambios en el alcance cel proyecto.
62 DIRECCION Y GESTION DE PROYECTOS TIC

FUNIBER~
o 1 '"'· ... -
~· :..."
-
• 1•11;...m•1••·· • ..- ,..,
.r
"
--
'" '
1
; ' ., ... •· •
1
•11
"'
·...
Gestión del tiempo
Identificar las actividades específicas que se deben desarrollar para cumplir con las
6.1 Definición de actividades principales entregas del proyecto.
6.2 Secuenciación de las actividades Identificar y documentar las distintas interrelaciones entre actividades.
Estimación de los recursos de las Estimar el tipo y cantidad de recursos necesarios para desarrollar cada actividad.
6.3
actividades
Estimación de la duración de las Estimar el número de jornadas laborales que se necesitarán para terminar cada actividad.
6.4
actividades
Analizar la secuencia de actividades, duraciones, requerimientos de recursos y
6.5 Desarrollo del programa restricciones para elaborar el programa del proyecto.
6.6 Control del programa Controlar los cambios del programa del proyecto.
Gestión del Coste
Desarrollar una aproximación (estimación) de los costes de los recursos necesarios para
7.1 Estimación de costes completar las actividades del proyecto.
Asignar la estimación general de costes a cada uno de los elementos de trabajo para
7.2 Presupuesto de costes establecer u.n coste base.
Identificar los factores que generan variaciones de costes y controlar los cambios que se
7.3 Control de costes produzcan en el presupuesto del proyecto.
Gestión de la Calidad
Identificar qué normas de la calidad son relevantes al proyecto y determinar cómo
8.1 Planificación de la calidad cumplirlas.
Ejecución del Aseguramiento de la Aplicar las actividades planificadas para asegurar que el proyecto emplea todos los
8.2 calidad procesos necesarios para cumplir con los requerimientos de las normas.
< Realizar un seguimiento de los resultados específicos del proyecto para determinar si
;;;
8.3 Ejecución del Control de la calidad cumplen las normas más importantes sobre la calidad e identificar la manera de eliminar
....< las causas de un desarrollo no satisfactorio.
;;;
~
> Gestión de Recursos Humanos
z
::::>
z Identificar, documentar y asignar las funciones, responsabilidades y relaciones jerárquicas
·O 9.1 Planificación de los Recursos Humanos
ü del proyecto, y crear el plan de gestión de personal.
<
o
5 9.2 Adquisición de equipo de proyecto Reunir los recursos humanos que sea necesario asignar al trabajo del proyecto.
u..
9.3 Desarrollo del equipo de proyecto Desarrollar las aptitudes individuales y de grupo para mejorar el desarrollo del proyecto.
Hacer seguimiento del rendimiento de cada miembro del equipo, cambiando y mejorando
9.4 Gestión del equipo de proyecto
factores que mejoren el desarrollo del proyecto.
Gestión de las Comunicaciones
Determinar las necesidades de información y comunicaciones de las entidades
10.1 Planificación de comunicaciones
involucradas en el proyecto.
Poner a disposición de las entidades involucradas en el proyecto la información necesaria
10.2 Distribución de información
en el momento adecuado.
Recopilar y distribuir la Información sobre el desarrollo del proyecto. Esto incluye el
10.3 Informe de realización
informe de situación, la evaluación del progreso y las previsiones.
Gestión de las Entidades Mane¡ar las comunicaciones para satisfacer los requerimientos y resolver los factores
10.4 relacionados con las entidades involucradas en el proyecto.
Gestión del Riesgo
11.l Planificación de la gestión de riegos Decidir el enfoque, plan y ejecución de las actividades de gestión del riesgo del proyecto.
Determinar qué tipo de riesgos es probable que afecten al proyecto y documentar las
11.2 Idenuficación de riesgos
características de cada uno de ellos.
Evaluar la probabilidad de ocurrencia e impacto de los riesgos y priorizar los riesgos para
11.3 Análisis cualitativo de riesgos su análisis o acción futura.
11.4 Análisis cuantitativo de riesgos Analizar numéricamente el efecto de los riesgos identificados sobre los objetivos del
proyecto.
Desarrollar procedimientos y técnicas para mejorar las oportunidades y reducir las
11.5 Planificación de las respuestas a riesgos
amenazas respecto de los objebvos del proyecto.

FUNIBER
-
Q - •·~'"'·••la.JI• ._.,.u •• ,r:.:., ··l~i..:•••1.."t t::..1.._. . .-¡-¡, ... ,tTi
Monitorear los riesgos residuales, identificar nuevos riesgos, ejecutar planes de reducción
11.6 Monitoreo y control de riesgos
de riesgos y evaluar su efectividad a lo largo del ciclo de vida del proyecto.
Gestión del Abasteci miento
12.1 Planificación de Compras y Adquisiciones Determinar qué aprovisionar y cuándo.
Documentar los productos y servicios requeridos e identificar los potenciales

12.2 Planificación de la contratación
suministradores.
12.3 Petición de respuestas de proveedores Obtener presupuestos, ofertas y propuestas adecuadas.
Revisar las ofertas, escoger a los posibles proveedores y negociar un contrato escrito con
12.4 Selección de proveedores
cada uno de ellos.
12.5 Administración del contrato Manejar el contrato y la relación entre el comprador y el vendedor.
Completar y establecer cada contrato, incluyendo la resolución de cualquier tema abierto,

12.6 Cierre del contrato
y finalizar la relación contractual.
Tabla 2.3. Procesos de gestión de proyectos.
2.3.3 GRUPOS DE PROCESOS DE GESTIÓN

<
z
<
u
Los grupos de procesos de gestión, Project Management Process Groups , son «
~
agrupaciones de procesos de gestión de proyectos relacionados con las cinco fases de <
o
un proyecto: Iniciación (I P) , Planificación (PI), Control (CoP), Ejecución (EP) y Cierre .,e¡
<
a:
(CIP). Los grupos de procesos son independientes al área de aplicación o enfoque de la <
industria en donde se desarrolle el proyecto ; sin embargo , tienen claras dependencias y

se ejecutan en la misma secuencia para cada proyecto.
El nivel de actividad de estos grupos de procesos durante el proye cto varía en el tiempo
tal como ilustra la

Grupo Grupo Grupo Grupo de procesos Grupo

de procesos de procesos de procesos de seguimiento de procesos
de iniciación de planificación de ejecución y control de cierre
Nivel de
interacción
ent re
--
procesos
-- - -
Inicio Finahzac1on
TIEMPO
<
z
<
!:
I!"'< Figura 2. 20: La interacción de los grupos de procesos de gestión a lo largo del proyecto.
o
..
a:
~
- ITiTi) .
'·.1 ..... ~1•1•1•.air::i
- -
- l•llit •:........: •J.."1 -
1• '--'- ' - '" U.OUOlJJ
IP Iniciación Define y autoriza el proyecto o una fase del proyecto.

....< 1
e
z Define y refina objetivos, y planifica las acciones necesarias para
....::> pp Planificación conseguir los objetivos y el alcance bajo el cual el proyecto fue
~
concebido.
Integra personal y demás recursos para llevar a cabo el plan de gestión

EP Ejecución
del proyecto en cuestión.
Ejecuta mediciones y monitoreos regulares del progreso, identificando

CoP Control las variaciones con respecto al plan, para así tomar acciones correctivas
cuando sea necesario con el fin de lograr los objetivos del proyecto.
Formaliza la aceptación del producto, servicio o resultado, y conduce al

CIP Cierre
proyecto o fase de proyecto hacia un término ordenado.
Tabla 2.4. Grupos de procesos de gestión.
2.3.4 RELACIÓN ENTRE GRUPOS, ÁREAS Y PROCESOS
La relació n entre gr upos, áreas y procesos se presenta en la . En esta tabla,

cada "x" indica la pertenencia de procesos de área de conocimiento en un grupo de
procesos.

FUNIBERff
Aunque los procesos en cada área pueden aparecer como elementos aislados con
conexiones bien definidas, en la práctica pueden solaparse e interaccionar de una
manera no detallada aquí.
Estos procesos interaccionan entre ellos, así como con los procesos en las otras áreas
de desarrollo. Cada proceso puede requerir esfuerzos de una o más personas o gr upos
de personas, según sea n las necesidades del proyecto. Gene ralmente, cada proceso
ocurre al menos una vez en cada fase del proyecto.
,, ..
r
w·
~
~ mi @f¡) ~
Gestión de la Integración X X X X X
Gestión del Alcance X X
Gestión del Tiempo X X
Gestión del Coste X X
Gestión de la Calidad X X X <
~
u
Gestión de Recursos Humanos X X o:
~
<
Gestión de las Comunicaciones X X X o
.,"'
u
Gestión del Riesgo X X

Gestión del Abastecimiento X X X
Tabla 2.5. Relaciones entre grupos, áreas y procesos.
La gestión de proyectos habitualmente se espera sea aplicada a cabalidad luego de leer

un manual o sencillamente asistir a un curso. No obstante , en este sentido, desde el
área de gestión de proyectos , se ha planteado que las p rácticas de gestión han de
usarse según las competencias que requiera un proyectista conforme madura en su
experiencia en gestión de proyectos.
En este sentido se han presentado en la literatura modelos llamados modelos de

madurez de gestión de proyectos , cuyo fin es proveer un marco que permita reconocer
qué tipo de competencia se r equiere en diferentes estados de madurez en gestión de
proyectos.
66 DI RECCIÓN Y GESTIÓN DE PROYECTOS TIC

FUNIBER
Un modelo de madurez de gest ión de proyectos, en el área de Proyectos , aglutina y

organiza en niveles de madurez un conjunto de criterios de gestión con el fin de orientar
las actuaciones de los proyectistas. Estos niveles, según Ward, aparte de regular las
competencias necesarias conforme el gestor de proyectos aprende y asimila , actúan en
sí mismos como metas a conseguir por las organizaciones desde el punto de vista de la
calidad de su gestión de proyectos.
La literatura muestra que todos estos modelos de madurez han surgido o se basan
dir ectamente en el Capabi/ity Maturity Model del Software Engineering lnstitute (SEi) en
Estados Un idos.
A continuación se presentará el CMM para luego pasar a re v isar algunos modelos de

madurez en gestión de proyectos .
2 .4.1 CAPABILITY MATURITY MODEL (CMM)
A partir de noviembre de 1986 el SEi , a requerimiento del Gobierno Federal de los

Estados Unidos de América , desarrolló una primera definición de un modelo de madurez
de procesos en el desarrollo de software , que se publicó en septiembre de 1 987 .
<
"'
<
!:: Para Pa ulk et al. , el CMM es un marco que representa recomendaciones para
"'
~
>
organizaciones de software que desean mejorar la calidad y capacidad de sus procesos
"'
::o
z
-O
de software. En este sentido , el CMM describe las prácticas de ingeniería de software y
ü
<
e
z
de gestión que caracterizan a las organizaciones conforme mejora (madura) su proceso
::>
u..
pa ra desarrollar y mantener software.
Se añade en particular que un proceso de software se puede definir como un conjunto

de actividades, métodos, prácticas , y transformaciones que las personas usan para
desarrollar y mantener software y los productos asociados. Para cada área de proceso
define un conjunto de buenas prácticas que habrán de ser:
• Definidas en un procedimiento documentado.
• Provistas (la organización) de los medios y formac ión necesarios.
• Ejecutadas de un modo sistemático , universal y' uniforme (instituc ionalizadas).

• Medidas.
• Verificadas.
A su vez estas Áreas de Proceso se agrupan en cinco " niveles de madurez ", de modo
que una organización que tenga institu c ionalizadas todas las prácticas incluidas en un
nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.

GE STI Ó N DE PR OY ECTOS
FUNIBER
a.- Niveles de madurez
La mencionada madurez se valoriza en función de cinco niveles de madu rez.
Un nivel de m adurez es una plataforma en el camino de conseguir una mejora en un

proceso de software . Cada nivel de madu r ez considera un conjunto de objetivos de
procesos que una vez satisfechos estabilizan una compon ente del proceso de software.
A continuación se describe cada uno de los niveles de madurez del CMM.
• Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el

desarrollo y mantenimiento de software. Aunque se utilicen técnicas correctas de
ingeniería, los esfuerzos se ven minados por falta de planificación. El éxito de los
proyectos se basa la may o ría de las veces en el esfuerzo personal , aunque a
menudo se producen fracasos y casi siempre retrasos y sobre costes. El resultado
de los proyectos es impredecib le.
• Repetible . En este nivel las organizaciones disponen de unas prácticas

<
institucionalizadas de gestión de proyectos , existen unas mét ricas básicas y un ~
....
a:
razonable seguimiento de la cal idad . La relación con subcontratistas y clientes está ~
<
o
gestionada sistemáticamente. ..
~
<
• Definido. Además de una buena gestión de proyectos, a este nivel las "'<
~
¡;;
organizaciones disponen de correctos procedimientos de coordinación entre ~
>
z
grupos, formación del personal, técnicas de ingenie ría más detallada y un nivel más ::i
z
~
avanzado de métricas en los procesos. Se implementan técn icas de r evisión po r u
<
o
z
pares (peer reviews). "
"-
• Gest ionado . Se ca racteriza por que las organizaciones disponen de un conjunto de

métricas significativas de calidad y prod u ctividad, que se usan de modo sistem ático
para la toma de decisiones y la gestión de riesgos. El software resultante es de alta
calidad.
• Optimizado . La o rganización completa está volcada en la mejora continua de los

p rocesos. Se hace uso intensivo de las métricas y se gestiona el proceso de
innovación.
Las organizaciones que utilizan este modelo para mejorar sus procesos disponen de una
guía úti l pa r a o r ientar sus esfuerzos . A demás, el S Ei p r opo r ciona formació n a
evaluadores certificados (Lead Assesors) capacitados para evaluar y certificar el nivel
CMM en el que se encuentra una organización . Esta certificación es requerida por el US
DoD , pero también es utilizada por multitud de organizaciones de todo el mundo para
valo rar a sus subcontrati stas de software.

Se considera típico que una organización dedique unos 18 meses para progresar un
niv el , aunque algunas consigue n me jorarlo. En cualquier caso r equiere un amplio
esfue rzo y un compromiso intenso de la di recció n.
Co m o consecuencia, m u chas or gan iz aci o n es que realizan funciones de factoría de

software o, en general, outsourcing de pro cesos de software, adoptan el modelo CMM
y se cert ifican en alg uno de sus niveles. Est o explica que uno de los países en el que
más organizaciones certificad as exi sta sea India, donde han florecido las factorías de
software que trabajan para clientes estadounidenses y europeos.
Críticas sobre el modelo
Frecuentemente se critica al modelo CMM por no ser más específico en la definición de los procesos. Para
guiar a las organizaciones a definir y mejorar sus procesos indica qué actividades han de rea lizar, pero nada
sobre cómo hacerlo. Esto es así tanto en lo referente a la ingeniería como a las herramientas o técnicas de
gestión, aunque hace una curiosa excepción en las revisiones por pares (peer reviews).
"~ Del mismo modo, aunque insiste continuamente en la necesidad de las métricas, no da ninguna guía concreta
u
;;: del tipo de métricas que son aceptables para una correcta práctica profesional.
Los técnicos se quejan a menudo de la enorme carga de " papeleo" que impone el modelo, viéndolo mas como
un mecanismo de control por la dirección que una herramienta que les ayude en su trabajo.
~
""'
~
También resulta muy complejo, más todavía el CMMI, lo que hace que durante algún tiempo resulte para
"'~
?: mucha gente algo esotérico.
z
::::>
z
-o
u
"oz
.;:
Capability Inmaturity Model
Con mucho sentido del humor, y bastante conocimiento de causa, Anthony Finkelstein describió que hay
organizaciones que no han alcanzado siquiera el nivel 1 de CMM (en el que aunque sea de modo heroico se
llega a producir software), proponiendo que existen niveles negativos o de inmadurez. Este «Modelo de
Incapacidad e Inmadurez», que fue refinado posteriormente por Tom Schorsch, incluye tres niveles de idiotez:
• O Tonto. Organizaciones negligentes. Impiden cualquier desarrollo de software con éxito. Su gran
preocupación es la reutilización del software.
• -1 Estúpido. Organizaciones obstructivas. Imponen procesos contra-productivos para impedir cualquier
avance. Se concentran en desarrollar entornos de desarrollo y repositorios.
• - 2 Lunático. Organizaciones desdeñosas. Desprecian cualquier institucionalización de buenas prácticas.
Su gran objetivo es la programación automática.
DIRECCIÓN Y GESTIÓN DE PROYECT OS TIC 69

FUNIBER f~
GEST IÓN DE PROYECT OS
a . 1 .- Otro s modelos CMM del SEi
a . 1 . 1 .- SE-CMM
El Modelo de Capacidad y Madurez en la Ingeniería de Sistemas fue publicado por el SEi

en noviembre de 1995. Está dedicado a las actividades de ingeniería de sistemas.
Define 18 áreas de proceso divididas en tres grupos:
• Ingeniería (7) .
• Proyectos (5).
• Organ izativ as (6).
No utiliza niveles de madurez generales sino que en cada área de proceso una
organización puede alcanzar un determinado nivel de madurez.
<
z
<
Al igual que el SW-CMM, ha sido integ rado en el CMMI. u
5;:
<
o
o:
a.1.2 .- IDP-CMM w
"'<
"'<
¡...
El Modelo de Capacidad y Madurez para el Desarrollo Integrado de Productos fue
~
propuesto como un borrador por el SEi en 1997, pero quedó integrado en el CMMI al ~
"
:::>
publicarse este en el año 2000. "
·:?
u
<
o
z
::>
a.1 .3 .- P-CMM u..
Modelo de Capacidad y Madu rez para Recursos Humanos.
a.1 .4. - SA -CMM
Modelo de Capacidad y Madurez para la Adquisición de Software .
a . 1 .5 .- SSE-CMM
El System Securíty Engineering Capabi/ity Maturity Modelo Modelo de Capacidad y

Madurez en la Ingeniería de Seguridad de Sistemas es un modelo deriv ado del CMM y
que describe las características esenciales de los procesos que deben ex ist ir en una
organización para asegurar una buena seguridad de sistemas.
Ha sido desarrollado por la "lnternation a/ Systems Security Engineering Association

(ISSEA ) " , organización sin ánimo de lucro patrocinada por un buen número de
compañías dedicadas a la seguridad de sistemas.
70 DIRECC IÓN Y GESTIÓN DE PROYECTOS TIC

FUNIBERf1; . . . . . . . . . . . . . . . . . . . .m11:111111. . . . . .
~. . . . . . . . . . . . . . .. . . .
Nació a partir de 1 993 bajo los auspicios de la Agencia Nac ional de Seguridad (NSA) de
los E.U.A., con la participación de numerosas compañías de los sectores de tecnologías
de la información, seguridad y defensa. La primera ve rsión data de 1997 y la actual
(v3.0) fue publ icada en junio de 2003.
Pretende servir como:
- Herramienta pa ra que las organizaciones evalúen las prácticas de ingeniería de

segu rid ad y definan mejoras a las mismas.
- Mecanismo estándar para que los clientes puedan evaluar la capacidad de los
proveedores de ingeniería de seguridad.
- Base para la organización de un mecanismo de evaluación y certificación.
A diferencia del CMM original, las áreas de proceso no están agrupadas en func ión de
los niveles de madurez, sino que define 22 áreas para cada una de las cuales se puede
<
z alcanzar un nivel en función del cumplimiento de unas " características comunes".
<
~
5
"'o< Existen 11 áre as de procesos de ingeniería y otras 11 dedicadas a la gestión de
5
"' proyectos y organización.
<
"'<
!:
"'5 El método de evaluación se denomina SSAM (SSE-CMM Appraisa/ Method).
>
:5
.a
u
b.- Arquitectura por niveles
o<
5
u..
A su vez, los niveles de madurez se componen de áreas de proceso claves (Key Process
A reas) , que contienen prácticas clave (Key Practices) organizadas a su vez en rasgos
comunes (Common Features) .
- Las Key Practices Areas (KPA) indican las áreas en que una organ ización debería
concentrarse para mejorar su proceso de software .
- Las Common Features (C F) son un conjunto de prácticas agrupadas dentro de

un área clave o necesidad .
- Las Key Practices (KP) son las acti vidades e infraestructura que con tribuye de
manera más efectiva a la implementación e institucionalización de cada área
clave.
c.- La madurez por temas
El carácter organizado r del CMM ha lugar a toda una serie de variaciones ligadas al
desarrollo de software como un producto. Por ejemplo , la versión de CMM para la

GE STI ÓN DE PROYECTOS
FUNIBER
adquisición de software 1 , o ap licaciones má s concre tas acerca de cómo mejorar la

capacidad de gestión del conocimiento que sugieren Baskerville y Pries-Heje.
No obstante el CMM presenta una peculiaridad que requiere ser mejorada según el
contexto de este trabajo. El CMM describe la madurez por niveles y plantea un camino
para conseguirlas. Sin embargo, como modelo es un patrón que plantea lo que hay que
medir por nivel, no distinguiendo si existen mejo ras parciales. Como instrumento de
medición posee un carácter excesivamente evaluativo más que formativo y, además,
deja a las organizaciones sin capacidad de mejoras parciales por temas , por procesos
críticos o más robustos.
SPICE es un modelo de madurez de origen europeo similar al CMM, pero con la

diferencia que las mejoras de capacidad del proceso se pueden conseguir por temas o
áreas. Por ejemplo, se puede alcanzar un nivel dos en documentación y un nivel tres en
el uso de métricas. Esta última cualidad es considerada en muchos de los modelos de
madurez de proyectos que a continuación se presentan.
<
~
u
~
z
2.4.2 CMMI <
o
.,"'
w
<
;;¡
<
El modelo de buenas prácticas de Capaci dad y Madurez Integrado (CM MI) es el sucesor ....
"'"'
de CMM. Fue desarrollado desde 1 987 hasta 1997, con el objetivo de real izar algunas ~
z
=>
mejoras re specto al SW-CMM e integrarlo con el SE-CMM y el IPD-C MM , que pasaban a z
-o
u
ser considerados como "obso letos". Fue creado por miembros de la industria, el <
e
2 ,,z
gobierno y el Instituto de Ingeniería de Software (Software Engineering lnstitute - SEl ). u.
Se lanzó la primera versión al mercado en 2002 .
El objetivo del proyecto CMMI es mejorar la usabilidad de modelos de madu r ez

integrando un conjunto de modelos orientados a la mejora de procesos de ingeniería del
software , ingeniería de sistemas, desarrollo de productos y adquisición de aplicaciones
ya existentes en un solo marco (framework).
Es un modelo que permite clasificar a las organizaciones de desarrollo de software

según una escala de cinco niveles de madurez y capaci dad . La clasificación en un
determinado nivel se realiza sobre la base del dominio y aplica ción que una organ ización
evidencia tener acerca de las áreas de proceso de dicho nivel, lo cual refleja el grado de
madurez de la misma y de los procesos que sigue para desarrollar software.
1. COOPER, JACK; FI SHER, MATI. (2002). Software Acquisition Capabllity Maturity Model (SA-CMM) versión 1.03 . Software
Engineering !nstitute. P. 115.
Enlace web: f"1 p ..... se cm Edw . bra} a::w·acts1re;:¡o-tc '.'2tr01J.cfm
2. SEi. Software Engineering !nstitute. Carnegie Mellen I nstitute.
Enlace web: ........¡¿_ . ~e .e~. ;;
72 D IRECCIÓN Y GESTION DE PROYECTOS TIC

FUNIBERff --------------¡¡¡¡¡¡~¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡:::;:¡~
CMMI es uno de los modelos más conocido y empleado a nivel mundial, convertido en
un estándar de facto, en lo referente a la Mejora de Procesos Software.
Existen cuatro diferentes disciplinas del Modelo CMMI, con el obje ti vo de cubrir
diferentes necesidades dentro de las Organizaciones (Desarrollo de Software, Servicios ,
Outsourcing y Adquisición de Productos). Estas cuatro disciplinas son:
CMMl-SW: Software.
CMMl-SE/ SW: + Ingeniería de sistemas.

CMMl-SE/ SW/IPPD: + Desarrollo integ ra do de procesos y productos.
CMMl-SE/ SW/IPPD/SS: + Gestión de proveedores.
CMMI proporciona una visión completa y estructurada para la mejora de los procesos
que intervienen en el desarrollo y mantenimiento de software. Algunos de los beneficios
<
que proporciona son:
z

::~ Mejora del alineamiento del software con la Estrategia de Negocio al integrar bajo una visión los
~ sistemas, los procesos, las personas y la tecnología lo cual permite tener las tecnolog ías alineadas lo cual
~
> define los servicios y funciones de TIC aportando el máximo valor exigido.
z
::>
z
-O Reducción en los costes y en las desviaciones en plazo de los " Proyectos software" al proveer un
ü conocimiento y administración de los requerimientos.
<
o
z
:::>
u..
Mayor eficacia en la detección de errores a lo largo del ciclo de vida de los "Proyectos software", reduciendo
drásticamente el número de errores que afecta directamente a los clientes y usuarios, al proveer un
conocimiento y administración de los riesgos y de exigencias de calidad.
Resultados más predecibles en los proyectos al proveer conocimiento y administración de la información

relevante al proyecto, del equipo y de las exigencias de los clientes.
Implementación de técnicas pro-activas de g estión, mitigando los riesgos que afectan a los
proyectos.
Liberación de tensiones, malentendidos y vacíos de responsabilidad en "Proyectos software' al proveer

mecanismos de control de conflictos de manera reactiva y proactiva.
Disposición de información de gestión útil a la hora de tomar decisiones ya sean éstas relacionadas
con la Gestión de "Proyectos software", bien con la mejora continua del "Proceso software'.
Mejorar el posicionami ento frente al mercado al tener información interna alineada con los objetivos
estratégicos y por ende en consonancia con información externa.
Tabla 2.6. Beneficios de la implantación CMMI.
DI RECCIÓ N Y GESTIÓN DE PROYECTOS TIC 73

CMMI es un Modelo de Madurez para la gestión en el proceso de desarrollo

de software caracterizado por identificar 3 dimensiones en las cuales se
p debe de enfocar una organización con el fin de lograr mejorar sus negocios.
Estas tres dimensiones son: las personas, los métodos y procedimientos,
y las herramientas y equipos. Se mantiene de esta manera la premisa de la
administración de procesos de que la calidad de un sistema o producto está
altamente influenciada por la calidad de los procesos usados para su
desarrollo y mantenimiento.
2.4.2.1 Descripción general del modelo CMMI
Estructura de base y co mpon entes del mode lo CMMI
El modelo CMMI tiene co m o base estructural la que se ilustra en la
<
z


z
:::>
LEYENDA z
·O
Prácticas ü
<
o
genéricas z
:>
Requeñdo u..
~
~
Figura 2.21: Componentes del modelo CMMI.
El modelo está compuesto de cinco element os que se describen a contin u ación.
• Área de proceso (Process Area) . Un área de proceso es un grupo de prácticas

relacionadas con una tarea específica para consegui r un conjunto de objetivos. Al
ejecutarlas en conjunto se satisface una meta importante como mejora sig nifica t iva
en esa área . Las áreas de proceso distin guen los distintos niveles de madurez del
modelo CMMI.
• Metas específicas (Specific Goals). Las metas específicas se aplican o definen

sobre un área de proceso y se ocupan de describi r las características únicas que
deben ser implementadas para satisfacer el área de proceso .
74 DIRE CCIÓN Y GESTIÓN DE PROYECTOS TIC

GESTI ÓN DE PROY ECTOS
• Prácticas específicas {Specific Practices) . Una práctica específi ca es una actividad

considerada como importante pa ra lograr la meta específica a la cual está asociado
en un determinado área de proceso. Las prácticas específicas y las gené r icas
consideran subprácticas, que son interpretaciones y descripciones detalladas de las
prácticas , y que resultan útiles para la mejo ra del proceso.
• Características comunes {Common Features). Son características que se observan

de manera general en las distintas áreas de proceso, organizadas en las prácticas
genéricas. Hay cuatro características comunes principales:
a) Compromiso a realizar.
b) Hab ilidad a real izar.
c) Administración de la implementación.
d) Verificación de la implementac ión.
• Met as Genéricas {Generic Goals) . Metas que se denominan genéricas debido a que
<
:¡ aparecen en varias áreas de proceso. El logro de una meta genérica en un proceso
u
B
>'. significa control mejorado en planeación e implementación de los procesos
<
o
o:
w asociados con el área de proceso.
"'
:!
...;;;"'< • Prácticas Genéricas {Generic Prac tices ). Las prácticas genéricas buscan la
"'> institucionalización para asegu rar que los procesos asociados al área de proceso
"
=> sean eficaces , reutilizables y durables . Las prácticas genéricas son categorizadas
"
·~
V por las metas genéricas y las características comunes .
<
o
5
u..
2.4.2.2 Descripción de los niveles del modelo CMMI
El mode lo CMMI tiene dos posibles representac i ones denominadas escalonada y

continua. En el equipo de desa r rollo de CMMI había defensores de ambos tipos de
representaciones. El resultado fue la publicación del modelo con ambas
rep resentac io nes: continua y escalonada.
No son equivalentes, y cada organización puede elegir aquella que considere que mejor
se adapta a sus características y prioridades de mejora. En el caso de la representación
continua permite evaluar el nivel de madurez de una organización en todas las áreas de
proceso , mientras que la representación escalonada permite evaluar el nivel en cada
área independientemente.
El modelo en su representac ió n escalonada { ) establece 5 N iv eles de

Madurez {Maturity Leve!) para clasificar a las organizaciones , en función de qué áreas
de procesos consiguen sus objetivos y se gestionan con principios de ingeniería. La

FUNIBER
visión escalonada definirá a la organización dándole en su conjunto un nive l de madu rez

del 1 al 5.
Niveles de madurez
r ¡
Área de proceso 1 Área de proceso n
Objetivos genéricos
--
capacidad
realización
<
z
<
§"'
"'<o
.."'
w
<
;;;
<
Figura 2.22: Estructura CMMI (representación escalonada) .
"'"'u
>
z
:::J
En su representación continua, por el contrario, el grado de madurez se expresa en z
-O
'-
<
términos de perfiles que se establecen sobre el nivel de dominio o aplicación de áreas de o
z
proceso determinadas. La vis ión continua de u n a organización mostrará la "'

u_
representación de nivel de capacidad de cada una de las áreas de proceso del modelo.
Área de proceso 1 Área de proceso n
Objetivos específicos
.._______,_ --------
E
1 1
•••
es_p_ec_ í-
fic-as > Niveles de capacidad <:
Figura 2.23: Estructura CMMI (representación continua).

2.4.2.3 Comparativa CMM versus CMMI
Las principa les diferencias con el SW-CMM, además de la inclusión de las tres nuevas
disciplinas para int egrar los tres modelos antiguos , son:
- Pone un mayor énfasis en el uso continuo de métricas.
Insiste en la necesidad de la trazabilidad desde los requerim ientos al producto

final.
Desglosa y detalla las áreas de proceso rel ativas a la ingeniería.
Cambia el nombre a los nive les 2 y 4 que pasan a llamarse "gestionado" y

"gestionado cuantitativamente".
2.4.2.4 Evaluación
Las organizaciones no pueden ser certificadas CMMI. Por el cont r ario , las
organizaciones so n evaluadas y recibe un a calificación de nivel 1 -5 si sigue los niveles
de M adu rez. En caso de que q uiera la organización , puede coge r áreas de proceso y en
vez de por niveles de madurez puede obtener los nive les de capacidad en cada una de
"'"' las Áreas de Proceso, obteniendo el " Perfil de Capacidad" de la Organización.
>
z
::>
z
o • Las organizaciones que se somet en a este tipo de evaluaciones norm almente
e;
<
o
z buscan .
~
"'" • Comparar los procesos de la organización con las mejores prácticas CMMI y
determinar qué mejoras se pueden hacer.
• Para infor mar a los clientes externos y proveedores acerca de que t ambién los
procesos de la organización se comparan con las mejores prácticas CMMI.
• Para cumplir los requisitos contractuales de uno o más clientes.
p CMMI enseña el camino para alcanzar un nivel de madurez de la

organización o un nivel de capacidad de un área de proceso.
Dice: Qué hay que hace r
pero NO dice : Cómo hay que hacerlo

FUNIBER
2.4.3 MODELOS DE MADUREZ
Del área de gestión de proyectos se han considerado en este estudio los siguientes
modelos de madurez de proyectos, por su relevanc ia, impacto y presencia:
• Tril!ium mode/,
• Project Management Assessment,
• Management Maturity Mode/, e
• lnnovation Maturity Mode/.
2.4 .3.1 Trillium model
El modelo Trillium es un producto usado po r Bell Canadá para dar valor al desarrollo de
un producto y apoyar las capacidades de pro v eedores de telecomunicaciones o <
;¡
productos basados en tecnologías de la información existentes o futuros. El modelo ha ~
o:
sido diseñado para ser aplicado a sistemas de software ' empotrados' tales como >!
<
o
sistemas de telecomunicaciones , no obstante buena parte del modelo puede ser ..
o:
~
<
aplicado a otros segmentos de la indust r ia del software como sería el área de o:
<
Management lnformation Systems. ¡¡;
"'
;;
z
::o
Con respecto al CMM , el modelo Tri llium , se distingue en que:
define roadmaps en lugar de áreas c lave ;
- t iene una perspectiva orientada al producto, haciéndolo más general y de amplio

uso;
- da amplia cobertura a los aspectos que inciden o impactan en la capacidad del

proceso; y,
- se enfoca al cliente en lugar del desarrollo mismo.
Esto consigue que se definan prácticas que guían al proyectista sobre cómo conseguir lo
que desea un usuario /cliente donde , en lugar de señalar determ inadas metas que se
deben alcanzar con ci ertas prácticas de diseño, se buscan aquellas práct icas que
habiliten la consecución de lo que desea el usuario .
A semejanza del mode lo CMM , el modelo Trillium presenta una escala de cinco ni veles
de madurez:
78 DIRECCIÓN Y GES-IÓN DE PROYECTOS TI C

G ESTIÓ N DE PROY ECTOS
FUNIBERff c::=======~:=:¡:¡¡;;;;:;::::;:z:==::::===========:::::...mm....__..
• Nivel 1 . Desestructurado . En este nivel el proceso de desarrol lo es ad-hoc. Los

proyectos frecuentemente no puede n satisfacer objetivos de calidad o de
programación . El éxito posible se basa más en el trabajo de los individuos que en la
propia estructura e infraestructura organizacional.
• Nivel 2 . Repetible y orientado al proyecto. El éxito individual del proy ecto se

consigue a t ravés de una fé rr ea plani f icación y control de gestión de l pro y ecto ,
dando especial énfasis a los requ erimie ntos de gestión , técnicas de estimació n y
configuració n de l cambio.
• Nivel 3 . Definido y orientado al proceso. Aquí los pro cesos son definidos y
utilizados al ni v el organizacional , no obstante se acep ta que el pro y ec to se a
adaptado a las circ unstancias . Los pro c esos son co ntrolados y mejorado s. Se
incorporan requeri mie ntos ISO 9001 , como procesos de entrenam iento y au ditoría
intern a.
• Nivel 4 . Gest ionado e integrado . La monitorización y análisis del proceso son

usados como mecanismos clave en la mejora . Pro cesos de gestión de l camb io y
programas de pre v ención de defectos son integrados . Las herramientas CASE se
..
<
z
u
integran dentro del proceso .
§
..
:¡:
o • Nivel 5 . Completamente integ rado. Metodo logías formales son extens ivame nt e
~
"' u sadas. Repos itorios orga n izac ion ales so n usa dos para soporta r y mantene r la
<
..
;<
!:
historia del proceso de desa rrollo.
"'
o:
>
:5 b.- Arquitectura del modelo
z
!:?
u
<
o La arqu itectu r a de Trill ium igualm en te plantea una de s compo si ción pero co n u n a
5
u..
~
diferencia sustan cial con el CMM: no se co m ienza la descompo si ción desde los niv eles
de madurez , sino desde ocho áreas de capacidad (Capability A reas) , cada una de las
cuales contiene v arias roadmaps y estos últ i mos a su v ez cont i enen práct ic as
(Practices ), usados paulati namente por niveles de madurez ( 3 ).
3. Trillium. Model Description.

Enlace web: h'tc .HHi.SCI ou edu.au t·illlVT' t3modc3 html

FUNIBER
Modelo TRILUUM
Capacidad
de procesos 1 Áreas de capacidad
lmpoct;/
~--~"'
Metas:
· Organización
· Compromisos
· Cultura
L Roa~maps J
InOue~ Contiene
"'
Procesos
<
Funciones Prácticas
z
<
Técnicas :::
5
"'<o
"'
w
"'
<
"'....<
~~
z
~
z
-O
'o<"'
:!;
.:
Figura 2.24: Arquitectura del modelo Trillium.
De esta forma, la arquitectura de Trillium se caracteriza por poseer:
• Capability Areas : ocho áreas centrales de preocupac ión o prioritarias para el modelo
Trillium, cada una de las cuales se encuentra contenida por prácticas;
• Roadmaps : conjunto de prácticas relacionadas, enfocadas sobre un área o

necesidad organizacional , o un elemento específico , dentro del proceso de
desarrollo del producto; y ,
• Practices : acciones a desarrollar para conseguir una mejor capacidad del proceso,
cada una de las cuales se vincu la a un nivel de madurez.
La detalla la relación entre los elementos de la arquitectura 4 .
4. Trillium. Model Description.

Enlace web: ..,1 1 1. ... sa 1 .gu edu 2u1tr 1umlt3moCc3 btml

FUNIBERfJ .................................................
'1~:11••1• • .,_. r :/_• r:u• ~ J4f: ·ll"ii"f'r1 1.: , . , :L.., r..rt' ·=--J·,_. --·-- -:., ;1tl•·1L
_.;
~ ,.f:~::T· L"t
. "'.··
-;o :. !
'
ffi"El
2 3 4 5
1
Organizational Process Quality Qua!ity Management
10 20 5 o 35
Business Process Engineering
Human Resource Human Resource Development and
Development and Management 9 42 1 o 52
Management
Process Process Definition
Technology Managemen t
Process Improvement & 16 55 24 4 99
Engineering
Measurements
Management Project Management
Subcontractor Management
Customer-Supplier Relationship 74 29 4 o 107
Requirements Management
<
:¡ Estimation
u
;;
;: Qua!ity Systems Qua/ity System 14 15 2 2 33
<
o
~ Development practices Development Process
::: Development Techniques
"'<
I nterna/ Documentation
Verification & Validation 41 49 15 5 110
Configuration Management
Re-Use
Reliability Management
Deve/opment Environment Development Environment 4 6 1 1 12
Customer Support Problem Response System
Usabllity Engineering
Life-Cycle Cost Modelling
User Documentation
25 30 5 o 60
Customer Engineering
User Training
Total 193 246 57 12 508
Tabla 2.7. Arquitectura del modelo Trillium.
2.4.3.2 Project Management Assessment
El Project Management Assessment 2000 (PMA) es una metodología holística y una

herramienta de softwar e para la mejora de procesos de gestión en un medio ambiente
de gestió n de pro yectos. Se ofrece para dar soluciones a problemas de inflexibilidad, de
tiempo , de " no saber hacer " y , de falta de una mejora incremental.

FUNIBER
Para Lub ia niker , es un modelo donde deben integrarse prácticas gener1cas

(h erramienta s, procedimientos y estándares comunes al ámbito de gestión de proyectos
tomados del PMBOK) y específicas de la propia organización, para lo cual se cuenta con
un software.
El software es un producto orientado a defini r y especificar prácticas genéricas tomadas

de l PMBOK y otras específicas de cada problema y unirlas siguiendo el esquema de
prácticas que ofre ce el mismo PMBOK.
2.4.3.3 Project Management Maturity Model
El Management Maturity Model (PM3) se orienta a mejorar prácticas de gestión de

proyectos. Es un esfuerzo derivado de considerar la gestión de proyectos un proceso
crítico de la misión organizacional y de competencia vi t al a la organización.
El modelo se ha construido a pa rt ir de encuestas a org anizaciones que han llevado , <

z
<
obviamente, proyectos, buscando defin ir las prácticas de gestión que aplicaban. Según u
..."'
:i:
la última información disponible, el modelo se ha modificado hasta alcanza r unas 300 <
o
~
lecciones sobre gestión de proyectos en el ámbito corporativo . "'<
;:"'
¡¡;
Estas prácticas se han organizado en niveles de madurez. De estos niveles: ad-hoc,
"'>
w
abreviado , organizado, gestionado y adaptat ivo; se conocen 51 preguntas que permiten z

:::>
saber el nivel de una organización. o

ü
<
o
5
u.
"'
2.4.3.4 Innovation Maturity Model
El lnnovation Maturity Model (IMM) no es un modelo como tal, sino una propuesta para
el desarrollo de productos . Es una visión sob re cinco niveles de innovación: supe rficial
(Superficial) , mejoras en r asgos (Fea tu re Enhancements) , mejoras en so lu c iones
(So!ution Enhancements), soluciones impactantes (Breakthro u gh Solutions) y
'rompedora' (disrup tive).
2.4 .4 IMPLANTACIÓN DE LA MADUREZ
Todos l os modelos previos de una u otra manera buscan med ir o alcanza r un

dete rm inado nivel de competencia en gestión de proyectos. Consegu ir es ta
competencia requiere algunas precisiones de mayor detalle.
82 DIRECCIÓN Y GESTIÓN DE PROYECTOS T I C

FUNIBER }~f __________________ G_ E.ST. IÓ· N· D· E· PR
· O·YE
· C·T O.S

En cuanto a detalle, Peterson propone un modelo de madurez basado directamente en el
PMBOK de ocho niveles de madurez, cuya cantidad solamente se justifica en la medida
de conseguir una competencia paulatina incremental y más gradual. A grandes rasgos ,
tales niveles se ca racterizan por lo siguiente:
• Nivel l. No conocedor (non-awareness) . No existe conocimiento alguno sobre

gestión de proyectos.
• Nivel 11. Inicial. Se comienzan a introducir prácticas de gestión de proyectos.
• Nivel 111. Básico . Comienzan algunas tareas de gestión como asignación de

responsabilidades , documentación, hitos y manejo formal de información.
• Nivel IV. Repetible . Se establecen algunos procesos de gestión y se formaliza el

uso de determinadas he r ramientas. Ya existe algún plan de entrenamiento en
<
gestión de proyectos y se llevan algunas auditorías.
z
<
~
~
>:
• Nivel V . Avanzado . El entrenamiento y, las auditorías o seguimientos, son totales,
<
o
igualmente algunos procesos y herramientas son incorporados en su totalidad.
~
• Nivel VI. Bien-definido . Los niveles de autoridad y experiencia son completos , el
entrenamiento es avanzado , los procesos se integran introduciéndola
documentación y el uso de métricas.
• Nivel VII. Gestionado . Se promueven los incentivos, se introduce la certificación en

gestión de pro yectos . Se persigue un buen desempeño y mejorar la eficiencia y
efectividad.
• Nivel VIII. Optimizante . La mejora es continuada y sostenible.
Lo impo rtante de esta propuesta es el Nivel VIII , al dejar expl íc ito que alcanzar los
niveles de madurez no es un fin en sí mismo , sino un medio para garantizar una mejora
adaptativa y sostenida a lo largo del tiempo.
b.- Implantación
Respecto de la consecución de la competencia , White señala que una manera de

introducir técni cas de gestión que satisfagan los niveles de madurez del CMM es
siguiendo ciclos iterativos.
En este sentido, W hite propone un mecanismo para sensibilizar a los proyectistas en la

conveniencia de aprender a mejorar. Para ello White señala que se deben segui r ciclos
de mejora de forma paulatina , por ejemplo , comenzar con un ciclo As-Is donde se
D IRECCIÓN Y GESTION DE PROYECTOS TI C 83

FUNIBER
presentan las primeras prácticas de gestión, pasando luego a un ciclo de actua lización
de procesos e infraest ruct ura para alcanzar un nivel 2 y así, ejecutar un te rcer cic lo
orientado a conseguir el nivel 3 del CMM ( ).
1mciación Cierre Imc1aoon Cierre lmoaoón Cierre
~ ~ ~
t"-- ..._/ .... ·- .. "-- . /
Control - - - -• Plan1ficacion Control - - - - Planificación Control Planificación
........
E1ecuc1ón .................... E1ecuoon
.
''
............... Planear acciones
para conseguir
Anal zar lo t.pilcar acciones
Nivel l
realizado y para conseguir
corregir Nivel l
Figura 2.25: Implantación gradual. <

z
<
~
"'~
<
2.4.5 MODELOS DE MADUREZ EN USOS DI VERSOS ..

o
~
El concepto de 'Modelo de Madurez ' ha pasado de ser una idea organ izadora a un
modelo de actuación acerca de cómo mejora r el trabajo en un organ ización . As í como
desde el ámbito del software han ido su rg ien do diversos modelos como CMM hacia el
CMMI , o el m ismo Tr illium y su acercamiento a la es tr uctu r a del CMM , han i do
apareciendo en otros ámbitos. A cont inuación una lista de modelos de mad u rez que
siguen la estructura del CMM original y que ha ev olucionado hacia estructuras más
específícas de orientaciones más co ncretas.
• OualiPSo Open Source Maturity Model (0MM ) 5 , de apl icación a proyectos bajo
enfoque o f ilosofía FLOSS (Free/ Libre and Open Source Software ).
• A Competency-Based Maturity Mode!6, de aplicación en el método ITI L.
S. WJTIMANN, MARION; NAMBAKAM, RANGA. (2009). Working Document WD6.3.1 vJ CMM-/ike model for 055. From
QualiPSo, Quality Platform for Open Source Software, JST- FPG-JP-034 763. P. 140.
Enlace web : .~p· , 1•;w1 .. a.ia 1oso.org ornr:
6. McMAHON , DAN; HATHAWAY, LAURIE. (20 11). A Competency-Based Maturity Model to Reduce ITIL Adoption Risks. En
CIO.CO M. Febrero 9.
Enlace web: :...,: ., ,e o.ccri an e e•66353:; A Compet.,:icy Based r.:.atyrit•' 1:.odel tQ ReJ.ice ITIL ~doption
-'--' s'soLrc =r~s app! caior.s
84 DIRECCIÓN Y GESTION DE PROYECTOS T I C

• Outsourcing Management Maturity Mode/ (OMMM) 7 , de aplicación en la

externalización u outsorcing.
• Test Maturity Mode/ lntegration (TMMi) 8 , de aplicación en la implementación de

procesos de prueba .
• Architecture Capabi/ity Maturity Mode/ (ACMM) 9 , de aplicación en arquitecturas

informático-computacionales.
• Agite Maturity Model (AMM) 10 , de aplicación en el desarrollo de software llevado

adelante con la metodología Agile.
• Action-Research lnformation Systems Project Management 11 , de aplicación en

pro y ect os de invest igación t eórico-prácticos de Si stemas de Info rm ación.
<
z
;s
°'
u
:r
<
o
"'
~
"' Es acept ado que la información es un recurso estratégico que debe ser administrado.
<
;:
<
t:
Esta afirmac ión , normal hoy en día, ya la tenía considerada la gestión de proyectos.
"'
::; Pero no proveía medios detallados para hacerlo, salvo escuetas y genéricas alusiones a
>
z
:::> la importancia de contar con sistemas de información computar izados o sistemas
z
~
u
<
informáticos) adecuados y a la existencia de una estrategia y de recursos e inversión
o
z
:>
u.
para poseerlos y tenerlo s en funcionamiento. Situaciones como ésta, han llevado en el
campo de la informáti c a a contar con prácticas de gestión de TIC. Estas práctica s
suelen operar en infraestructuras predecibles y eficientes , con el fin de reduc ir costos
de soporte y de mejorar la calidad del servi ci o a los c lientes cumpliendo con las
regulaciones existentes en el medio donde se esté opera ndo .
Estas prácticas se h an org anizad o en los ll amad os Marcos de Referencia , que no son
más que mode los de actuación resultado d e la recopil ació n y si st ematización de
7. POWER, MARK J.; DESOUZA, KEVIN C. ; BONIFAZI, CARLO; POWER, MARK J. (2006). The Outsourcing Handbook: How
to Implementa Successfu/ Outsourcing Process. Koga n Page limited. P. 225.
Enlace web: t t:p: /1 ..... "".lazo com OLtSuurcng-Handboo!.,--rr, .;GJent-Sucu::ssfu1 -Process CR U7-1º~- ~ ;oa
8. TMMI. (2002). The Test Maturity Model Integration (TMMi).
Enlace web: t r o. ...... : ..... - r:,,."'d2~ 1 Q~.orc ht~ ~~r-· .. ef.~ : rr'
9. DoC. (2003). 1T Architecture Capability Maturity Model.
Enlace web: '" :i: ,r:s -; - . ;¡r;¡ oM 2rc ... 1;. c.u•e ,;pc'S-doc a·::ri C"ao•7. "tr:1
Enlace web: .·c10 os.:;r:: -::c. ; ~e - . .Jh e :c0c S:os 'S:c.c;;. cc.t;:i.., coc:..rne,.,:c COr)te-.: p ooOl 002'..:0 ;.jf
10. AMBLER, SCOTT. (2010). The Agi/e Maturity Model( AMM ).
En lace web: rttp · / crco::s.c0,..., architPctt, re-aod-des1ori 22420¡oos
11. ESTAY, CHRI STIAN; PASTOR, JOAN. (2002). A Maturity Mode/ for Information Systems Action-Research Project
Management. En ECIS 2002, The Xth European Confereoce on Information Systems. Pp. 28-38. Junio 6-8. Gdansk,
Poland.
DIRECCIÓN Y GEST ION DE PROYECTOS TIC 85

GESTIÓN DE PROYECTO S
FUNIBER
prácticas de gestión (Morency, 2005). A continuación se revisan los más importantes

surgidos y en uso en los últimos años :
• ITIL,
• SGSI, y
• COBiT.
Estos Marcos de Referencia no se presentan como modelos a seguir (que si deben

usarse en los casos para los cuales sea necesario) , sino como mecanismos
org anizadores de prácticas de gestión. Por esta última razón , se completa esta lista de
modelos con la técnica de benchmarking, para contar con una herramienta de análisis y
comparación de elementos que puede usa rse para estudia r prácticas de gestión.
2.5.1 ITIL
<
z
:
<
o
Informa ción (ITIL: lnformation Technology lnfrastructure Library) se ha convertido en el
~
estándar mundial de facto en la Gestión de Servicios Informáticos. Iniciado como una ::::
a:
guía para el gobierno del Reino Unido, la estructura base ha demostrado ser útil para las ::
V>
5
organizaciones en todos los sectores a través de su adopción por innumerables >
z
::>
compañías en el sector público y privado como base para consulta , educación y soporte z
-o
u
de herramientas de software. <
o
z
:::>
IL
Esta metodología provee un marco de trabajo para la gestión de servicios de

Tecnologías de Información, ya que es una recopilación de las mejores prácticas tanto
de l sector público como del sector privado. Estas mejores prácticas se dan en base a
toda la experiencia adquirida con el tiempo en determinada actividad , y son soportadas
bajo esquemas organizacionales complejos, pero a su vez bien definidos y , que se
apoyan en herramientas de evaluación e implementación.
"ITIL no tiene propietario, pero continúa evolucionando a través de la coalición

de compañías enfocadas en mejorar las operaciones de IT" 12 .
ITIL pasó de los o riginales 14 volúmenes al actua l conjunto de 8 volúmenes en la

versión 2 de ITIL, incluyen:
12. DESIANO, L. (2007). DemystifyingITI L. P. 8.

Enlace web: .... _ . .,-::.'~.hptone.C,Jr1' por;¡ e; e ÜOCi.ffj'er;ts QPrryc;ti'v -io 0 -2QITIL 11:/

Libro 1. Soporte de servicios.

Libro 2. Entrega de servicios.
Libro 3 . Perspectiva de negocio.
Libro 4. ICT Administración de infraestructura.
Libro 5. Administración de aplicaciones.
Libro 6 . Admin istración de seguridad .
Libro 7. Planificación e implementación .

Libro 8 . Administración de activos de software.
2.5.1.1 El Marco de Referencia de ITIL
~ Planeación de la implementaóón de la
~ admini stración de servidos
§
"'<
o
~
<
"<
Soporte
de servicios
.!
La Adm1n1straoón 8'
perspectJVa dela oe
infraestructura
del negoao
de ltC B
Entrega !I
de servidos
Administración
de la segundad _.,;,>
Administración de aplicaciones
Figura 2. 26: Marco de Referencia de ITIL13 .
13 . CARTLIDGE, ALISON ; LILLYCROP, MARK. (Eds) (2007). An Introductory Overv¡ew of ITIL@ VJ. versión 1.0. itSMF. P.
SS. Enlace web: h'jp: . . 1, t-es>-rnanagement-pr2c;;ce.co'"" ".r:-r:c' :5 = :.- :uc>o1. '- ,1e1. of
CI.. ..¡3 DO'
DIRECCIÓ N Y GESTJON DE PROYECTOS TIC 87

I TIL p r ovee la guía de las "mejo r es p r ácticas" sobre t odos l os aspectos de la

administración de servicios y cubre todo el espectro de personas, procesos, productos y
asociados . ITI L fue diseñada y desarrollada en la década de los ochentas, pero ha sido
revisada y actualizada de manera constante para alinearla con las prácticas más
modernas, sistemas distribuidos e Internet. ITI L es el enfoque de administración más
util izado pa ra la ent rega y sopo rt e de se rvicios e infraestructura de TI en todo el mundo.
ITIL y sus módulos f ue ron desa rrollados dentro de un marco de referencia complet o.
La muestra el ambiente y la estructura dentro de la que fueron creados los

módulos. Ilustra la relación que cada uno de los módulos de Entrega de Servicios y
Soporte de Servicios son el núcleo del marco de refe rencia de procesos.
Los contenidos y las relaciones ent re l os dife rentes mód u los en esencia son los
siguientes 14 :
• Entrega de Servicios (Service Delivery). Cubre los procesos requeridos para la

planeación y entrega de servicios de T I de calidad y ve a los procesos a un plazo <
z
<
u
más largo asociados co n la mejo ra de la calidad de los servicios entregados. ~
:E
<
o
• Soporte de Servicios (Service Support). Describe los procesos relacionados con el "'w
"'
sopo rte diario y las actividades de mantenimiento asociadas a la provisión de
servicios de TI.
• Administración de la Infraestructura de TIC (ICT lnfrastructure Management). Cubre z

-o
todos los aspectos de la administración de infraest ructura desde la identificación de ü
<
o
z
los reque r imien t os del negocio, el proceso de cotización , pruebas, instalación, ::>
u..
distribución, operación continua y optimización de los compone ntes de T IC y

servicios de TI.
• Plane ación de la Implem entación de la Admini stración de Servi cios (Planning to

lmplement Serivice Management) . Examina los aspectos y tareas involucradas en la
planeació n, implementación y mejora de procesos de Adm inistració n de Servicios
en una organizació n. También hace referencia a los problemas asociados al Cambio
Cultu ral y Organizaciona l, el desarrollo de una visión, de una estrategia y el mét odo
de enfoque más ap ropiado.
• Administració n de Aplicac iones (Application Management). Describe cómo

administrar las aplicaciones desde las necesidades iniciales del negocio, y durante
todas las etapas del ciclo de vida de la aplicación, hasta e inclusive, su retiro. Pone
énfasis en asegurar que los proyectos y estrategias de TI estén alineados con las
14. ITIL. ITIL Foundation for IT Setvice Management

Enlace web: t D .. • \ :· .-of'1c º s1t1; .e.u=._

G ESTIÓN DE PROY ECTOS
del negocio d u rante todo el ciclo de vida de la aplicación, para asegura r que el
negocio obtenga el mejo r valor por su inversión.
• La Perspectiva del Negocio (The Business Per sp ective) . Provee una guía que ayuda
al personal de T I a entender como puede contribuir a los objetivos del negocio y
como sus ro les y ser vicios puede n alinea rse y aprovecharse de mejo r manera para
maximiza r su contr ibució n .
• A dministración de la Seguridad (Security M anagement) . Detalla el proceso de la

planeación y administración de un nivel de segu ridad definido para la información y
los se rvicios de TI, incluye ndo todos los aspectos asociados con la respuesta a
incidentes de Seguridad. Incluye también la ev aluación y administración de riesgos
y vuln erabilidad es, y la implementac ión de contra m ed idas qu e se justifiqu en en
costo .
2.5.1.2 Adm inistración de Servicios (Service Management)

<
z
<
u
;;¡ La Administr ación de Servicios es la parte central de ITIL. Diferentes autores usan el
u
;¡;
<
o t érmino en distintos contextos. En este trabajo u sa remos la definición más amplia que
..
~
< se refiere a cualquier aspecto de la administración de la provisión de servicios de TI que

"'
~ comprende tanto la Entrega de Servicios (Service D elivery) y Soporte a Servicios
"'"'
~ (Service Support) de ITIL.
z
:::>
·~
u A con t inuación se describirá brevemente cada una de las part es compo n entes de la
o<
z
Ad m inistración de Servicios según Gavilán 15 .
"'"
a) Soporte de Servicios (Service Support)
Esta área esta compuesta por cinco procesos y una función:
• Gestión de la configuración (Configuration Managemen t). Este proceso se encarga

de la definición de un mo d elo lógico de la infraest ructura de T I (inc l uyendo la
definición de categorías, relacio n es, atributos y estados de los ítem s de
configu ración) así como de la identificación, control y mantenimiento de las
versiones de los Ítems de Configuración (C I: Configuration ltems) existentes. Es el
proceso responsable del mant enimiento de la base de datos d~ configu raciones
(CMD B: Configuration Managemen t Data Base).
• Gestión del Cambio (Change Man agement). Este proceso se encarga del control y
aprobación, si procede , de los cambios en la infraestructura. Se asegura de que
15. GAVILÁN, IGNACIO. (2007). ITIL - Information Techno/ogy lnfrastructure Library.

Enlace web: ~.,ac o~a,1lan ,_J..,, doc r::.c·o:Jtor aies r,1A J007010"< •·- !TI pi.(

G ESTIÓ N DE PROYECTOS
FUNIBER
existan procesos y métodos para la rea lización de camb ios de forma que se
m inimice el impacto en la ca lidad y conti nuidad de los servicios .
• Gestión del Incidentes (lncident Management). Este proceso se encarga del

tratamiento de los incidentes (eventos qu e se salen de la dinámica normal del
servicio). Un incidente puede co rr esponde r r ealmente a una situación de
degradación del se rvicio o, sencillame nte, tratarse de consultas o pet iciones por
parte del usuario (solicitudes de servicio). El objetivo fundamenta l de la gestión de
incidentes es restaurar cuanto antes el servicio (con independencia de que se
resuelva o no el presunto problema de fondo) y mantener la comunicación entre la
organización de T I y los usuarios. De cara a restaurar el servicio, con frecuencia
proporcionará soluciones temporales , quedando la resolución real del problema para
el pro ceso de gestión del prob lem a.
Las tareas fundamentales que realiza son:
Detección y registro del incidente.

<
z
- Clasificación del incidente y soporte inicial. <
Invest igación y diagnóstico .

<
Resolución y recuperación. "'<
v.
~
Cierre del incidente. >
z
:::>
z
• Gestión del Problema (Problem Management) . El objet ivo de este proceso es ·O
'-'
<
anal izar los fallos del servicio , identificando la causa raíz de esos fallos y sugiriendo Q
...5
tanto soluciones temporales para su uso futuro como solicitudes de cambio (RFC :
Request fa r Change) para solucionar los problemas. Las dos áreas del proceso de
gestión del problema son:
Control de problemas: identificación de la causa raíz de los fal los .
- Control de errores: corrección de los problemas y generación de información

sobre problemas y errores conocidos.
• Gestión de la Entrega (Release Management). Este proceso se encarga del

almacenamiento del software autorizado en la librería de software (DS L: Oefinitive
software Library) y del almacenamiento de piezas de hardware (DHS : Definitive
Hardware Store) , así como de la distribución y entrega de software y hardware .
• Centro de Servi cio al Usuario (Service Desk) . Se trata de una función , no de un

proceso. El Service Desk sirve como punto único de contacto (SPOC: Single Point
Of Contact) entre la organización de T I y los usuarios del servicio .
Fundamentalmente, ejecuta el primer nivel de gestión de l incidente , recibiendo ,
r esolviendo o escalando incidentes ya sean relativos a fallos en el servicio o

GESTIÓ N DE PROYECTOS
solicitudes de servicio. Se trata de una evolución de los Cal! Center o Help Desk
tradicionales incluyendo la resolución (cuando tie ne procedim ientos para ello) de
incidentes y peticiones de servicio.
b) Provisión de Servicio (Servíce Delívery)
Esta área esta com puesta por cinco procesos:
• Gestión de la Capacidad (Capacity Management) . Este proceso se asegura que

siempre existe la capacidad de TI (hardware, capacidad de proceso, etc.) necesaria
pa ra la prestación de servicio, equilibrando la obtención de capacidad con los
costes que esto supone. Es responsable de la gestión de la demanda, de la
elaboración del Plan de Capacidad y del mantenimiento de la base de datos de
capacidades (C DB : Capacity Data Base).
• Gestión de la Dispon ibilidad (Avai/ability Management). Se ocupa de aspectos de la

disponibilidad del servicio de TI , buscando y evaluando puntos únicos de fallo ,
<
z
u
< evaluando rie sgos y proponiendo las contramedidas pertinentes. Utiliza medias de
~
<
:E 'dow ntime' como el T iempo Promedio Para Reparar (MTTR : Mean Time To Repair),
o
."
w de 'uptime ' o d isponibilidad como el T ie mpo Promed io Entre Fallos (MTBF : Mean
:> Time Between Failures) y de fiabi lidad como el Tiempo Promed io Entre Incidentes
!"
:;; del Sistema (MTBSI: Mean Time Between System lncidents).
~
>
z
:::¡
z
• Gestión de a Continuidad de Servicio de TI (IT Service Continuity Management). Es
!:?
u
< muy similar al proceso de Gestión de Disponibil idad siendo la principal diferencia el
o
z
::>
u. alcance de los mismos . El proceso de Continuidad de Servicio se enfoca más en
grandes desastres como terremotos, guerras, inundacione s, etc. evalu ando r iesgos
y proponiendo contramedidas. Mantiene un Plan de Continuidad del Servicio de TI
que debe formar parte de un Plan de Continuidad del negocio en general. En este
plan se definen las resp onsa bilidades y procedimientos en caso de cr isis y la vuelta
a la normalidad.
• Financia! Management for IT Services (Gestión Financiera de Servicios de IT) . Se

enca rga de la gesti ón financiera de los servicios de TI , incluyendo las actividades
de pr esupuesto, contabilidad analít ica, establecimiento de precios, políticas de
cobro, etc.
• Gestión del Nivel de Servicio {Service Leve/ Management). Proceso que se encarga
de la gestión de la calidad y cantidad de servicio entregado al client e. Mediante los
Ac u erdos de Nivel de Servicio (S LA: Service Leve/ Agreement) se establecen las
características detalladas del se rvicio a entregar y sirve de acuerdo fi r mado con el
c liente. Se suele partir de los Requ erimientos de Nivel de Servicio (SLR: Service
Le ve / Requirements ) requis itos de servicio que el cliente solicita y, tras la
negociación , se traduce en un SLA firmado. Otros tipos de acuerdos son los
DIRECCION Y GESTION DE PROYECTOS T IC 91

GESTIÓN DE PR OYECTOS
FUNIBER
Acuerdos de Ni vel Operacional (O LA: Operational Leve/ Agreements) que son

similares a los SLAs pero se establecen entre departamentos de una empresa o los
(UC: Underpinning Contracts) que son contratos de soporte o acue rdos que se
establecen con un proveedor. Además, se debe establecer, a nivel interno un Plan
de Calidad de Servicio (SQP: Service Quality Plan) donde se define como se va a
operar para conseguir el nivel de servicio comprometido en el SLA. Además, el
proceso SLM, es responsable de mantener el catálogo de servicios que se pueden
ofrecer al cliente, y de definir y ejecutar el Plan de Mejora del Servicio (SIP: Service
lmprovement Plan). Si el Service Desk ejercía de punto único de contacto con los
usuarios del servicio , el SLM como proceso y el Service Leve/ Manager como rol,
son el punto único de contacto con el cliente entendido como la entidad
contratante del servicio.
2.5.1.3 Descripción de procesos de Soporte de Servicios
Por la importancia en este trabajo detallaremos los procesos componentes del área de <
z
<
Soporte de Servicios 16 .
u
"'
~
"
<
o
~
a) Proceso de manejo de incidentes "'
<
"'::
Su objetivo primordial es reestablecer el servicio lo más rápido posible para evitar que el "'"'
~
>
cliente se vea afectado, esto se hace con la finalidad de que se minimicen los efectos de z
:::>
z
la operación. <>
u
<
o
5
u.
Se dice que el proveedor se debe encargar de que el cliente no perciba todas aquellas
pequeñas o grandes fallas que lle gue a presentar el sistema. A este concepto se le llama
disponibilidad, donde el usuario pueda tener acceso al servicio y que nunca se vea
interrumpido.
Para este proceso se tiene un diagrama donde cada una de sus fases maneja
cuat ro pasos básicos que son: propiedad, monitoreo, seguimient o y comun icación.
En el proceso de manejo de incidentes vemos que se da como primer paso la detección

y registro del incidente cuando un sistema presenta alguna anomalía ó falla , y que esto
se puede traducir en un error en el sistema o que el usuario no puede hacer algo y
recurre a pedir ayuda.
Luego de ser identificado el incidente se hace una clasificación, viendo si el error que se
presenta es conocido o si nunca se ha presentado y de la mano va el soporte inicial. En
caso de que el incidente sea conocido se hace el procedimiento de solicitud de servicio
16. HERNÁNDEZ, CARLOS. ( 2007). Metodología Universidad Iberoamericana. Campus Ci udad de México.
92 DIRECCIÓN Y GESTIÓN DE PROYECTOS T IC

ejecutando los pasos a seguir según el manual de procedimientos para poder llegar a la
solución de una forma viable y eficiente.
Una vez que ya que se d i o una solución al incidente por medio del manual de
procedimientos se recurre a la documentación y contabilización del incidente, viendo
que tanta incidencia tiene este caso.
Finalmente , se hace una evaluación para ver si efectivamente se resol vió el incidente de
forma satisfactoria y en caso de ser afirmativa se cierra el incidente; el otro supuesto
sería que de la solución que se planteo no es lo suficientemente eficiente o acertada
para que resuelva el problema y se recurre a hacer una investigac ión y un diagnóstico
de la situación para ver cómo es que se puede atacar el problema para resol v erlo.
Detección y
registro del
incidente
Clasificación
y soporte
inicial
Procedimiento
de solicitud de
PROPIEDAD servicio
MONITOREO
SEGUIMIENTO
COMUNICACIÓN
Investigación
.,..__. y diagnóstico
Resolución y
recuperación
Cierre del
incidente
Figura 2.27 : Proceso de manejo de incidentes.

FUNIBER
Una vez que se tiene todo un contexto analizado se recurre a la ejecuc ió n de la

propuesta de solución del incidente y se hace un estudio para ver si el inc ide nte es
recuperable o si es caso perdido. La mayoría de los casos son recuperables , pero
cuando el nive l de daño es muy grande, se da el caso por perdido. Finalmente, se cierra
el incidente y esta solución se documenta en una base de datos a la que se le llama
base del conocimiento o Knowledge Database, en la misma se documenta todas las
soluciones, y se establecen los pasos a segui r para que en un futuro se hagan de forma
eficiente. De esta manera el momento de volverse a pre sen tar un inc idente, ya va a
estar documentado y esto hace que sea más fácil, rápida y eficiente su resolución .
b) Proceso de manejo de problemas
El Ob¡etivo de este proceso es prevenir y reducir al máximo los inc identes , y esto nos
lleva a una reducc ión en el nivel de incidencia. Por otro lado, nos ayuda a proporc ionar
soluciones rápidas y efectivas para asegurar el uso estructurado de recursos .
En este proceso lo que se busca es que se pueda tener pleno control del problema , esto <
z
<
~
se logra dándole un seguimiento y un monitoreo al problema. "':E
<
o
::;
"'
:::o:
<
Identificación ....
ldenbficacion ¡¡;
y registro del y registro del ~
problema error ::z
::>
z
-O
ü
<
o
Clas1ficac1on Evaluación z
,z
del problema del error
MONITOREO MONITOREO
SEGUIMIENTO SEGUIMIENTO
DE PROBLEMAS DE ERRORES
lnvestigac16n Registro y
y d iagnóstico resolución
del problema del error
RFC, Cierre del error

Resolución del y de los
problema. problemas
cierre asociados
Fig ura 2.28: Proceso de manejo de problemas.
En la se muestra este proceso particular, ya que se maneja en dos fases . La

primera esta rela cionada con lo que es el control del problema y la segunda es con el
control del error.
En lo que respecta a la fase de control del problema: primero se tiene que identificar el
problema en base a alguna sintomatología; ya que tenemos este antecedente , se pasa a

FUNIBERf; ......................... ...........................
~ --
G ESTI Ó N D E PROY ECT OS
la clasificación de los problemas, en este proceso al igual que en el proceso de manejo

de incidentes se ve si es un problema conocido, en caso de ser conocido, se recurre al
procedimiento de solicitud de servicio, donde se aplicarán las soluciones de acuerdo a
como están en el manual de procedimientos, en caso de no ser conocido se tend ría que
hacer una fase de investigación para ver qué es lo que genera el problema y más ta rde
hacer un diagnóstico para luego hacer una so licitud de cambio o RFC.
Esta solicitud de cambio implica que se va a tener que imp lem enta r la so l ución y,
finalmente se va a hacer una evaluación pa ra ver si se re solvió el problema de raíz. En
caso de que funcione esta solución se pasa a la documentación del proceso.
Con lo que respecta a la segunda fase del proceso, el control del error se hace por
medio de una identificación del erro r en general , posteriormente se hace un registro
para luego pasar a clasificar el error , después de la clasificación se recurre a una
evaluación de que tanto daño genero o puede llegar a generar el error , esto con la
finalidad de cuantificar los desperfectos que podría llegar a causar en caso de que el
<
~ error prevalezca y no se solucione , posteriormente se hace la resolución o co rrección
."'
u
del error, este puede deberse a varios aspectos , con figur aciones , falta de seguridad ,
..
:t
o inconsistencia de datos , etc.
"'"'"'
Este modelo tiene una fase muy d ifíci l, la de determinar qué problemas están asociados
y como es que al momento de cambiar algo en el sistema de forma uniforme, no se
altere el contenido y presente inconsistencias.
c) Proceso de manej o de configuraciones
Su objetivo es proveer con información real y actualizada de lo que se tiene configurado

e instalado en cada sistema.
Este proceso es de los más complejos, ya que se mueve bajo cuatro v értices que son:
- administración de cambios ,
- administr ación de entregas,
- administración de configuraciones y ,
- administración de procesos diversos.
El nivel de comp lejidad de este modelo es alto , ya que influ y en mu c has v ariables y
muchas de ellas son dinámi cas, entonces al camb ia r una o v aria s de ellas se afecta el
sistema en general , lo que h ac e que sea muy difícil de m anipular . Au nqu e es lo más
parecido a la realidad , porque nuestro entorno es dinám ico y las decisiones de unos
afectan a otros .

FUNIBERf~
Por ejemplo, en lo que respe cta a la administración de cambios vemos que se relaciona
directamente con la administración de incidentes y de problemas, lo que con lleva una
planeación, identificación, control , seguimiento del status, verificación y audito ría de
configuraciones , lo que hace que haya muchas variables.
En otro ejemplo la implementación de cambios implica que se tiene que hacer la

liberación y distr ibución de nuevas ve r siones, esto de da por un a fase de planeación ,
identificación, control, re visión del status, ver ificación y auditoría , que pueden depender
de la administración de las capacidades , ya que si no se cuenta con el software o con el
hardware, esta fase no se podría llevar a cabo; y así se haría con todos los niveles hasta
llegar al cie rre del control de cambios.
Incidente
<
z
<
u
5
:E
Problema <
o
..
;:¡
Errores e
M
: co~dos ~ o
B
Solicitudes
de cambio
Prueba,
implementación
y entrega de
cambios
Figura 2.29: Proceso de manejo de configuraciones.
d) Proceso de control de cambios
El objetivo de este proceso es reducir los riesgos tanto técnicos , económicos y de

tiempo al momento de la realización de los cambios.
Este diagrama al parecer es muy fácil de seg uir, pero en realidad no lo es, ya que entre
etapa y etapa se da una fase de monitoreo para ver que no se han sufrido desviaciones
de los objetivos.
96 DIRECC I ÓN Y GESTIÓN DE PROYECTOS TI C

FUNIBERf~
m¡¡:;¡¡;;;;w;;;;~::¡=:::a;im::::=c::!lmm. . . . . . . . . . . . . . . . .- -
Primero vemos que tenemos un regist ro y clasificación del cambio que se tiene que
hacer, se pasa a la fase de monitoreo y planificación, si el rend imiento es satisfactorio
se da la aprobación del cambio, y en caso de que el rendimiento sea malo se pasa a la
fase de reingenie ría hasta que el proceso f uncione adecuadamente , ya que se aprueban
los cambio, se construyen prototipos o modelos en los que se van a hacer las pruebas ,
se hacen las pruebas pe rtinentes pa ra ver las capacidades del sistema, ya que el
proceso esta probado se da la autorizació n e implementación; una v ez implemen t ado se
ve que no se hayan tenido desviaciones y se ajusta a las neces idades actuales que
también se le considera como revisión post-implementació n.
Registro y Monitoreo y
clasificación planificación
..
z

z
!:
V
<
o
z
::>
u.. Evaluación Implementación
<;
CONTROL MANEJO
DEL DE
CAMBIO PROYECTOS
Figura 2.30: Proceso de control de cambios.
e) Proceso de manejo de entregas
Su objetivo es planear y controlar exitosamente la instalación de software y hardware

bajo tres ambientes: ambiente de desarrollo , ambiente de p ruebas controladas y
ambiente real.

G ESTIÓ N D E PROYECTOS
FUNIBER
Este proceso tiene un diagrama que marca la transición que se da de acuerdo a los
ambientes por los que se va dando la evolución del proyecto.
En lo que respecta al ambiente de desarrollo vemos que se tiene que hacer la definición
de las políticas de entregas , la planificación de entregas , el diseño lógico de la
infraestructura que se va a implementar y la adquisición de software y hardware están
entre los ambientes de desa rrollo y de pruebas controladas , se requie r e que ambos
hagan pruebas sobre ellos.
En el ambiente de pruebas controladas vemos que se hace la construcción y liberación

de las configuraciones (nivel lógico), se hacen las pruebas para establecer los acuerdos
de aceptación; se da la aceptación total de versiones y de modelos , se arranca la
planeación y, finalmente las pruebas y comunicaciones; en lo que es el ambiente real
v emos que se da la distribución e instalación.
<
z
<
Ambiente de Ambiente real
~
desarrollo "'
"<
o
r ~
.,
Distribución e
Política de instalación
<
entregas
l "'<
;¡;
~
.. ~
>
z
::>
z
-O
Comunicación y ü
<
Planificación preparación e
z
de entregas de la entrega
::>
u.
..
• 1
Diseño,
desarrollo o
compra -· Construir y
configurar la
entrega
Planificación
de la
distribución
..
+ ,.....- 1
Ajustes y
pruebas
-
~
Aceptación
de la entrega
J
Ambiente de pruebas controladas
Figura 2.31: Proceso de manej o de entregas.
En la etapa del ambiente real es la que se ve de forma más concreta , ya que muchas
v eces no tenemos idea de todo lo que pasa hasta antes de la instalación.
98 D !RECC ION Y GESTIÓN DE PROYECTOS TIC

El proceso de entrega del servicio es el punto en que el usuario solicita un servicio y no

sabe que detrás de el servicio que esta recibiendo hay un sin fin de actividades y de
decisiones que se tu vi eron que tomar para que llegar a este punto .
Este proceso es el que requiere poner más cuidado, ya que en caso de haber fallas , el
primero en detectarlas o en percibirlas es el usuario , y eso genera que el cliente este
insatisfecho o molesto. Por lo general los usuarios no saben que para que puedan hacer
uso de los servicios , se paso por una fase de planeación , monitoreo, análisis y por un
sin fin de pruebas , con la intención de que en caso de que algo no funcione, se dé en la
fase de pruebas controladas y no en la fase de pruebas en amb iente real, donde el
mayor afectado es el cliente .
2.5.1.4 Alcan ce de ITIL
ITIL reconoce que no ex iste una solución un iversal para el diseño e implementación de
<
z
un proceso óptimo para la administración y entrega de servi c ios de TI de calidad . 17
<
u
~
~ ITIL se ha desar r ollado "orientado a procesos ", pero puede ser escalable y lo
o
~ su ficientemente flexible para ser adaptado a cualquier organización, desde pequeñas y
<
medianas, hasta organizaciones multinacionales o globales 18 .
'"
<
~
;¡;
a:
~
>
z
::;)
La gerencia de TI debe reconocer la i mportancia de su propio rol en soportar la
z
·O operación de la organ i zación . Debe coordinar y trabajar en conjunto con todos ,
ü
<
o
z facil itando el crecimiento, en lugar de permitir que la tecnología y la TI dicten y lleven el
::.
"-
negocio . Por lo tanto , es esencial que los asuntos y expectativas de los administradores
estén alineados con los objeti v os y estrategias de los administradores de TI . Por lo
tanto, los procesos de TI deben desarrollarse en base a la capacidad de T I para proveer
beneficios a la organ ización.
La única manera de consegu ir lo anterior es diseñar, planear e implementar servicios de

T I, usando la infraestructura de TI y procesos para su admin istración que perm itan la
entrega de la información y de las soluciones requeridas por el negocio. Las
organ izaciones más efectivas hoy en día, primero diseñan los roles de las personas , de
los asociados y pro c esos , para después conf igurar la tecnología necesaria para su
soporte y automatización. En las organizaciones verdaderamente eficientes, estos roles
y procesos están alineados al negocio, a los requerimientos del negocio y a los procesos
del negocio . Esto asegura que el negocio y los procesos de administración de TI así
como los sistemas tengan metas y objeti vos alineados 19 .
17. CARTLIDGE, ALISON ¡ LILLYCROP, MARK. (Eds) (2007) . An lntrodudory Overview of mL@ V3. versión 1.0. itSMF. P.
º"' "\
55 . Enlace : htt;. .. 1 . .•• best-riarageme~•-practice e..,., e .. mpdf ·sr.• F 6n Irtror c•c x e , o' TTI L V3 .1cf
18. Ibid.
DIRECCI ÓN Y GESTIÓN DE PROYECTOS T IC 99

FUNIBER
ITIL provee guías y arquitecturas de "mejore s prácticas" para asegurar que los procesos
de TI estén estrechamente alineados con los procesos de negocio, y que TI entrega
soluciones correctas y apropiadas para el negocio. ITIL no es un estándar, tampoco lo
son sus reglas o guías. Por lo tanto, ninguna herramienta, proceso ó persona puede ser
denominada "Compatible con IT IL ".
Se debe actuar con precaución si se desarrolla la Administración de Servicios de TI

dentro de una organización. Es fácil confundir o interpretar a ITIL como una herramienta
burocrática y como resultado , implementar procesos que inhiben el Cambio , en lugar de
facilitarlo. Es sumamente importante que ITIL sea implementado con un enfoque de
"adoptar y adaptar", de manera que se desarrollen procesos efectivos y apropiados.
Esto sólo se puede lograr dónde estén establecidas las métricas de negocio , lo s facto res
críticos de éxito (CSF: Critica! Success Factors) y los indicadores clave de desempeño
(K PI: Key Performance lndicators) de manera que se pueda medir el éxito de l a
implementación de los procesos y su mejora continua. La calidad y la medición de la
misma en términos de negocio, es otro principio fundamental de ITIL.
<
z
<
~
a) ITIL en organizaciones pequeñas "'~
<
o
"'
~
Desiano 20 plantea la implementación de ITIL según el tamaño de organización , hace "'

referencia a que ITIL fue desarrollado desde una necesidad existente , en mayor medida
en grandes emp resas u organizaciones, tales como el gobierno del Reino Unido. ITIL
está más orientado a grandes organizaciones , donde el control de procesos es una
necesidad más , que un lujo .
ITIL es popular con grandes empresas que asisten a miles de usuarios, porque mientras
los grupos de IT crecen en tamaño , hay una predisposició n natural para las discip lin as y
funcio nes internas a disgregarse, y por lo tanto genera una necesidad de más contro l de
procesos para coordinar el flujo de la información. Chequeos y balances son necesarios ,
ITIL ofrece el marco para permitir esto.
Sin embargo, en una organización con sólo cientos de computadoras, una sola persona
es probablemente responsable de todas las actividades de auditoría de software ,
manteniendo las actualizaciones e instalando aplicaciones nuevas o actualizadas. En la
Desiano indica qué procesos de ITIL son más ap lic ab le s basándose en el
tamaño de una organización.
19. LERUGA, G.; PALADINI R. (2005). Implementación de mejores prádicas bajo mL. En IT Service Man agement Forum
Argentina. En lace web: ht.c.11w1fü jts,.,,f-argentina.cc..,. &.:
20. DESIANO, L. (2007). Demystifying ITIL. P. 8.
En lace web: i-;:~ . ,\ . ..,-c:n: " "'e.ce ":" Port2!s/O Ci.:.c.;rreú~S Denwct1f\ ncc o20!Tlt..QO'
100 DIRECCIÓN Y GEST IÓN DE PRO YECTOS TIC

FUNIBERf~
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _¡¡¡¡m_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _
~r: :"::.. 1··~ - - ~

1 ll• •_Jaf . ...., 1 -~ '':.l• lT• tl.._-4
So po rte de servicios
• Administración de configuración
• Administración de incidentes
• Administración de problemas
• Administración de cambios
• Administración de versiones
Ent r ega de servicios
• Administración de nivel de servicio --

• Administración de disponibilidad
• Administración de capacidad
• Administración de continuidad de
<
z
servicio
:
<
o
"'w
"'
< Tabla 2.8. Aplicación de ITIL según el tamaño de la organización21 .
o:
<
....
¡;;
"'
E
z En lo que se refiere a ITI L, un talle no les queda a todos. Por lo tanto , para las
::>
z
-o organizaciones pequeñas , no todos los aspect os de IT IL deben ser implementados
u
o<
z
"formalmente ".
::>
u..
ITIL sí requ iere una inversión de recu rsos pa ra definir, implementa r, administrar y rever
cons t antemente ITIL pa r a asegu rar que está s iendo utilizado efec ti va mente y no de
manera contraproducente. Demasiados procesos de control pueden ser tan costosos y
perjud icia les como no tener suficiente de los mismos. El mensaje predominante es que
cada organización necesita encont rar un equilibrio significativo.
2.5.1.5 I mplementación de ITI L

22
Para Desi ano " la implementación de ITI L se un esfuerzo de largo plazo que toma
t iem po , posiblemente años , y que requiere compromiso d e todas las áreas d e la
organización. No hay atajos, y puede ser costoso. Estos procesos no son estándares, y
tampoco están pensados pa ra se rlo . Depende de cada o rganización det erminar que tan
lejos ir y cuánto es suficient e".
21. DESIANO, L. ( 2007). Demystifying m L P. 8.

En lace web: bttp. \ 1'. ~.prophetone com Porta1s 1 01pocumer,t~'De""ys• ', ~ g r ,2)ITIL.oc:!f
22. !bid.
DIRECC IÓ N Y GEST IÓN DE PROYECTOS TIC 101

GESTIÓN D E PROYECTOS
FUNIBER
La implem entación de l as mej o res p r ácticas d ebe ser en etapas y que debemos
responder a las siguientes preguntas 23 :
¿Dónde queremos estar? Visión y Objetiv os .
¿Dónde estamos? Evaluación .
¿Cómo hacemos para estar donde queremos? Diseño e Implementación de

Procesos .
¿Cómo sabemos que sí llegamos? Definición de Métricas.
¿Cómo nos mantenemos? Mejo ra continua .
¿Cómo hacemos
¿Dónde queremos ¿Dónde estamos? ~ para estar donde ¿Cómo sabemos
estar? queremos? si llegamos?
<
z
--
"'>
~
Figura 2.32: Etapas de la implementación24 . z

::;¡
z
o
u
<
o
a) Consideraciones de la implementación §
u.
Para cada una de las recomendaciones de ITIL existen numerosas consideraciones de

implementación , algunas de consideraciones generales . 25
• Contar co n apoyo total de la alta gerencia .
• Asignar los tiempos de dedicación adecuados y respaldar a los dueños de procesos .
• Vencer la inercia de lo habitual y hacer esfuerzos pa ra seguir los nuevos procesos

de gestión definidos.
• Establecer un plan de cambio c ultural no lim itado al proy ecto .
• Los dueños de procesos deben transformarse en agentes de cambio.
• Mantener un p lan de capacitac ión adecuado.
23. LERUGA, G.; PALADINI R. ( 2005). Implementación de mejores práctJcas bajo ITIL. En IT Service Management Forum
Argentina. Enlace web: ht'O ...... •sm'-ar'."""t -ia c0-i ar
24. !bid.
25. Ibid.

GESTI Ó N DE PROYECTOS
• Usar los indicadores definidos para evaluar y tomar decisiones.
• Automatizar los procesos mediante herramientas siempre que sea posible.
• Premiar y celebrar los avances.
• Mantener una continuidad en el camino emprendido.
La consulto r a Xele re 26 plantea las siguientes mejoras que podrán surgir a partir de la
adopción de una gestión de TI basada en ITIL:
• Los procesos serán: Consistentes , Repetibles , Aud itables , Verif icables.
• Disminuc ión del tiempo de duración de los incidentes .
• Lenguaje común para el planeamiento de procesos .
• Resultados de encuestas de satisfacción.
• Al ineac ión entre IT y el negocio.
• Racionalización del hardware y del software .
<
• Mejor gestión de recursos.
;¿
....<
¡;;
~ Muchos autores coinciden que ITI L no describe en términos absolutos " cómo" los
>
z
=> procesos deberían ser implementados. Los detalles quedan a criterio del implementador.
..,z Sin embargo , las metas y los indicadores claves del desempeño para cada proceso
ü
<
están bien definidos, así se t iene un mapa claramente defin ido para med ir el éxi to 27 .
o
...5
2.5.2 SISTEMA DE G ESTIÓN DE LA SEGURIDAD DE LA I NFORMACIÓN ( SGSI )
Un Sistema de Gestión de la Seguridad de la Información (SGSI) es, en primera

instancia , un sistema de gestión , es decir, una herramienta de la que dispone la gerencia
para dirigir y controlar un determinado ámbito , en este c aso , la s egur idad de la
información.
Un SGSI tiene como objeti v o prioritario dotar a las empresas de un proceso

estructurado que permita asegurar la pri vacidad de la información organizacional. SGSI
es la abreviatura utilizada en castellano . El concepto equi v alente en inglés es ISMS ,
siglas de lnformation Security Management System.
26. XELERE, SERGIO. (2006). ¿Qué es mL? Una introducción. I EEE.

En lace web : "C\O h'W1\.1eee.org.ar dN.r.oads 2006-hrabins~ y· 1;i.pdf
27. DESIANO, L. (2007). Demystifying ITIL. P. 8.
Enlace web: http:' www. orophetorie: com portals1 O/Docum<>nt< Derwstify1'loºe20ITI L. pcf
DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC 1 03

Antes de nada explicitar que en este contexto , el término Información engloba a todo
aquel conjunto de datos organizados en poder de una entidad que posean valor para la
misma, independientemente de la forma en que se guarde o transmita (escrita , en
imágenes, oral, impresa en papel, almacenada electrónicamente, proyectada, enviada
po r correo, fax o e-mail, t ransmitida en conversaciones, etc.), de su origen (de la propia
organización o de fuentes ext ernas) o de la fecha de elaboración.
D D
a Da ªtos
to tos
s
<
z
:
<
o
::;
"'
Figura 2.33: Componentes de un sistema de Gestión de Seguridad de la Información.

Fuente: www.iso27000.es
La definición de seguridad de la info rma ció n según ISO 27001, co n siste en la

preservación de su confidencialidad , integridad y disponibilidad , as como de los
sistemas implicados en su tratamiento, dentro de una organización. Estos tres té rmin os
constituyen la base sobre la que se cimien t a todo el edificio de la seguridad de la
información:
• Confidencialidad: la información no se pone a disposición ni se re vela a individuos,

entid ades o procesos no autorizados.
• Integridad: mantenim iento de la exactitud y complet itud de la información y sus

métodos de proceso.
• Disponibilidad: acceso y utilización de la información y los sistemas de tratamiento

de la misma por parte de los individuos , entidades o procesos autorizados cuando
lo requieran.

FUNIBERfj .................................................. --
Para garantizar que la seguridad de la información es gestionada correctamente, se debe

hacer uso de un proceso sistemático, documentado y conocido por toda la
organización, desde un enfoque de riesgo empresarial. Este proceso es el que
constituye un SGSI .
Garantizar un nivel de protección total es virtualmente imposible, incluso en el caso de

disponer de un presupuesto ilimitado . El propósito de un sistema de gestión de la
seguridad de la información es, por tanto, garantizar que los riesgos de la segu ridad de
la información sean conocidos, asumidos, gestionados y minimizados por la
organización de una forma documentada, sistemática , estructurada, repetible , eficiente
y adaptada a los cambios que se produzcan en los riesgos , el entorno y las tecnologías .
Este proceso es el que constituye un SGSI, que podrá considerarse, por análoga co n
una norma tan conocida como ISO 9001, como el sistema de calidad para la seguridad
de la información. Es este precisamente el concepto central sobre el que se constru ye
ISO 27001.
<
z
<
u
B
:i:
a) Fina lidad de un Sistema de Gestión de Seguridad de la Información
<
o
~
"< La información, junto a los procesos y sistemas que hacen uso de ella, son activos muy
;;¡
<
....
importantes de una organización. La confidencialidad, integridad y disponibilidad de
"'« información sensib le pueden ll egar a ser esenciales para mantener lo s niveles de
~
z
:::i competitividad, rentabilidad, conformidad legal e imagen empresarial necesarios para
z
~ lograr los objetivos de la organización y asegurar beneficios económicos.
u
<
o
z
:>
u.
Las organizaciones y su s sistemas de información están expuestos a un número cada
vez más elevado de amenazas que, aprovechando cualquiera de las vulne rabi lidades
existentes, pueden someter a activos c ríticos de información a diversas formas de
fraude, espionaje, sabotaje o vandalismo. Lo s virus informáticos, el hacking o los
ataq u es de denegación de se rvicio son algunos ejemplos comunes y conocidos, pero
también se deben considerar los riesgos de sufrir incidentes de seguridad causados
vo luntaria o involuntariamente desde dentro de la propia organización o aquel los
provocados accidentalmente por catástrofes naturales y fallos técnicos.
El cumplimiento de la legalidad, la adaptación dinámica y puntual a las condiciones

va riables del entorno, la protección adecuada de los objetivos de negocio para asegurar
el máximo beneficio o el aprovechamiento de nuevas oportunidades de negocio, son
algunos de los aspectos fundamentales en los que un SGSI es una herramienta de gran
utilidad y de importante ayuda para la gestión de las organizaciones.
DIRECCIÓN Y GESTIÓ N DE PROYECTOS T I C 105

FUNIBER~
~ ---Amenazas
Aprovechan
Vulnerabilidades
Protegen de ... .J'':::---__ - ---- Exponen

/ Aumentan
e =~ ---- Disminuyen
e~
Imponen
/ /'---
Requenmtentos
de segundad
Marcan
Impactan
s: se
matenahzan ,,.,.--
Aumenta
Valor de los
ac:tJvos
~enen
Figura 2.34: Análisis de Riesgos de Seguridad de la Información organizacional.
Muchas veces , el nivel de seguridad alcanzado por medios técnicos es limitado e

<
insuficiente por sí mismo. En la gestión efectiva de la seguridad debe tomar parte activa z
<
~
toda la organización, con la gerencia al frente , tomando en consideración también a ~
"'
<
o
clientes y proveedores de bienes y servicios . El modelo de gestión de la seguridad debe
~
contemplar unos procedimientos adecuados y l a planificación e implantación de
controles de seguridad basados en una evaluación de riesgos y en una medición de la
eficacia de los mismos.
El Sistema de Gestión de la Seguridad de la Información (SGSI) ayuda a establecer estas

políticas y procedimientos en relación a los objetivos de negocio de la organización , con
objeto de mantener un nivel de exposición siempre menor al niv el de riesgo que la propia
organización ha decidido asumir .
Con un SGSI, la organización conoce los riesgos a los que está sometida su información
y los as ume , minimiza , transfiere o controla mediante una sistemática definida,
documentada y conocida por todos , que se revisa y mejora constantemente.
b) Estructura de un Sistema de Gestión de Seguridad de la Información
El modelo de un Sistema de Gestión de la Seguridad de la Información basado en ISO

28
27001 se puede mostrar gráficamente como una pirámide de cuatro niveles .
28. Estructura equivalente a la planteada en el ámbito de la gest ión de la calidad según I SO 9001.
10 6 DIR ECCIÓ N Y GESTIÓN DE PROY ECTOS TIC

GE STIÓN DE PROY ECTOS
Manual
de
seguridad '\.
Procedimientos
Instrucciones
Checklists
Formularios
Registros
Figura 2.35 : Estructura Modelo de Sistema de Gestión de Seguridad de la Información.

<
z Fuente : www.1so27000.es
<
u
;;
r<
o En la siguiente tabla se muest r a esquemática los niveles que componen el SGSI y la
~
documentación asociada a cada Nivel :
Inspira y dirige todo el sistema, el que expone y determina las

Manual de seguridad intenciones, alcance, objetivos, responsabilidades, políticas y
directrices principales, etc., del SGSI.
Aseguran, en el nivel operativo, que se realicen de forma eficaz la

Procedimientos planificación, operación y control de los procesos de seguridad de
la información.
Instrucciones, checklists y Describen cómo se realizan las tareas y las actividades específicas
formularios relacionadas con la seguridad de la información.
Proporcionan una evidencia objetiva del cumplimiento de los

requisitos del SGSI; están asociados a documentos de los otros
Registros
tres niveles como output que demuestra que se ha cumplido lo
indicado en los mismos.
Tabla 2.9. Niveles de un modelo de Gestión de Seguridad de la Información.
Uno de los componentes primordiales en la implantación exitosa de un Sistema de

Gestión de Seguridad de la Información es la implicación de la dirección. No se trata de
una expresión retórica , sino que debe asumirse desde un principio que un SGSI afecta
fundamentalmente a la gestión del negocio y requiere, por tanto , de decisiones y
acciones que sólo puede tomar la ge r encia de la organización. No se debe caer en el
error de considerar un SGSI una mera cuestión técnica o tecnológica releg ada a niveles

FUNIBER
inferiores del organigrama; se están gestionando riesgos e impactos de negocio que son
respon sabil idad y decisió n de la dirección.
A la dirección de la organización se le asigna también la tarea de , al menos una vez al

año, revisar el SGSI, para asegurar que continúe siendo adecuado y eficaz.
c) Integración del Sistema de Gestión de Seguridad de la Información con

otros sistemas de gestión
La gestión de las actividades de las organizac iones se realiza , cada vez con más
frecuencia, según sistemas de gestión basados en estándares internacionales:
- se gestiona la calidad segú n ISO 9001,
- el impacto medio-ambiental según ISO 14001 o
- la pr evención de riesgos laborales según OHSAS 18001.

<
z
<
Ahora, se añade ISO 27001 como estándar de gestión de seguridad de la información. '-'
~
>:
<
o
Las empresas tienen la posibilidad de implanta r un número variab le de estos sistemas de ~
.,
<
gestión para mejorar la organización y benef icios sin imponer una ca rga a la
"...<
organización. ;;;
~
~
z
::i
El objetivo último deberá ser llegar a un único sistema de gestión que contemple todos z
·O
ü
los aspectos necesarios para la organización, basándose en el ciclo de m ejora continua <
o
z
común a todos estos estándares. De todas formas, una revisión exhaustiva de la ...
:::>
""
IS027001 evidenc ia la alta correlación existente y se puede intuir la posibilidad de
integrar el sistema de gestión de seguridad de la información en los sistemas de gestión
existentes ya en la organización. Algunos puntos que suponen una novedad en ISO
27001 frente a otros estándares son la evaluación de riesgos y el establecimiento de
una declaración de aplicabilidad (SOA), aunque ya se plantea incorporar éstos al resto
de normas en un futuro.
2.5.3 COBIT
COBIT (Control Objectives far lnformation and related Technology) se desarrollo y

mantiene el (ITGI: IT Governance lnstitute) desde 1998 con el objetivo de crear
estándares internacionales para la gobernabilidad de TI en las empresas. Un impulso
importante ha tenido COB IT debido al Acta Sarbanes-Oxley23, vigente desde el 2002, y
que obliga a las empresas que t ranzan sus acciones en USA a controlar rigurosamente la
generación de sus estados f inancieros.
1 08 DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC

COBIT ayuda a salvar las brechas existentes entre riesgos de negocio, necesidades de
control y aspectos t écnicos. Propo rc iona "prácticas sanas " a t r avés de un Ma rco
Referencial de dominios y procesos y presenta actividades en una estructura manejable
y lógica. Las "prácticas sanas " de COBIT rep resentan el consenso de los expertos, las
cuales ayudarán a optimizar la inversión en info rmación.
El desa rrol lo de COBIT ha resultado en la pu blicación de 29 :
• Resumen Ejecut ivo, el cual propo rciona el entendimiento y conciencia sobre los
conceptos clave y princip ios de COBIT y el Marco Referencial donde se identifican
los cuatro dominios de COBIT y los co rrespond ientes 34 procesos de TI.
• Marco Referencial, que describe en detalle los 34 objeti vos de control de alto nive l
e identifica los requerimientos de negocio para la información y los recursos de TI
que son impactados en forma prima ria por cada objetivo de co ntrol.
• Objetivos de control , los cuales cont ienen dec laraciones de los resultados deseados
<
~ o propósitos a ser alcanzados mediante la implementación de 302 objetivos de
u
¡: controles detallados y específicos, a través de los 34 procesos de TI .
<
o"
"'w • Guías de auditoría , las cuales con ti enen los pasos de audit orio correspond ientes a
"'
<
;;¡
<
....
cada uno de los 34 objetivos de control de TI de alto niv el pa ra pr oporciona r
¡;;
a:
~
asistenc ia a los auditores de sistemas en la revisión de los procesos de TI co n
>
z
:J respecto a los 302 objetivos detallados de control recomendados para proporcionar
z
o
ü a la ge rencia ce rteza o una recomendacione s de mej oramiento ;
<
e
z
.z
""" COBIT es un marco de referencia para establecer un conjunto de procesos , que una vez
establecidos, permitirían tene r el área de T I perfectamente organizada , con procesos
medibles , eficientes, y con un mode lo de madurez que facilita el mejoram iento continuo
y la ejecución de las auditorías 30 .
2.5.3.1 Marco de referencia COBIT
COBIT define las actividades en un modelo general de procesos compuesto por cuatro
dominios:
1. Planifica r y Organ izar (PO).
2 . Adqu irir e Implementar (Al ).
29. !SACA. COBIT framework for IT Governance and Control.

Enlace web: http: : ... w. saca.ora ~.no .. ledge -Center cobit pa~\,,;" O er•.1e1'> .as;;ix
30. SAFFIRIO, MARIO. (2007). La COBIT y la organización del área informática. Marzo, 3.
Enlace web: r,::p "1'st;f• 10 ?rdpress.ccm '2l.07 '03 03 :a-co· .-y-12-oraan•·aL M-de1-a•ea-1n'or~a: ca'

FUNIBER
3. Proveer y Soportar (DS).
4. Monitorear y Evaluar (ME).
Estos dom inios corresponden con las áreas de responsabilidad tradicionales: planificar,
construir, ejecutar y monitorear. La muestra gráficamente el modelo COBIT
y lar relaciones entre los dominios:
8
1
Información
/~¡ Planeación y
<
z
<
~
~
>:
<
oa:
Monitoreo Recursos de TI w
organización "'
::
a:
<
....
¡;;
~
~
z
=>
z
Entrega y -o
Adquisición e ü
<
soporte implementación o
z
"
u..
Figura 2.36 : Modelo de Referencia COBIT31.
COBIT es un marco de referencia que entrega un modelo de procesos y un lenguaje

común para que cada quien en la organizac ión pueda visual izar y gestionar las
actividades de la TI , a continuación los 4 dominios que CO BIT propone 3 2 .
a) Plan ificar y Organizar (PO)
Este domin io abarca la estrategia , la táct i ca , y su preocupac1on es identificar las

maneras como las TI pueden contribu ir , de la mejor forma po sible , al logro de los
objetiv os de negocios de la empresa . La ejecución de la v is ión estratég ica requiere de
planificac i ón , d ifusión y gestión para diferentes perspecti v as. Una organización
3 1. !SACA. COBIT framework for IT Governance and Control.

Enlace web: ••. c;aca.org t ?· .l.!dge-C1:"':e. cob:~IPariPc:/Qyerv e ".as"x
32. !bid.

adecuada y una plataforma tecnológi ca acorde son necesarias. De modo que en este
dominio típicamente se tratan las siguientes interrogantes.
• ¿Están las TI alineadas con la estrategia de negocios?
• ¿Está la empresa utilizando a un nivel óptimo sus recursos informáticos?
• ¿Entiende todo el mundo de la emp res a lo s objetivos de las TI?
• ¿Son comprendidos los riesgos de TI y son debidamente gestionados?
• ¿Es la calidad de los sistemas informáticos adecuados a las necesidades del

negocio?
Este dominio considera los procesos:
• P01 Definir un plan estratégico para TI. Se requiere una planeación estratégica de
TI para administrar y dirigir todos los recursos de TI de acuerdo con la estrategia
<
z
<
del negocio y las prioridades . La función de TI y los participantes del negocio son
!::
"'>: responsables de garantizar que se materialice el valo r óptimo de los portafolios de
<
o
~
proyectos y se r vicios. El pla n estratégico debe mejorar el entendimiento de los
"' interesados clave re specto a las oportunidades y limitaciones de TI , evaluar el
<
;;:
;:. desempeño actual y aclarar el nivel de inversión requerido . La estrategia de negocio
"'~
~ y las prioridades se deben reflejar en los portafolios y deben ser ejecutadas por los
z
=>
z planes tácticos de TI , los cuales establecen objetivos, planes y tareas específicas,
·O
¡:;
<
o
entendidas y aceptadas tanto por el negocio como por TI.
z
"
u.
'9 • P02 Definir la arquitectura de información . La funció n de los sistemas de

información debe crear y actualizar de forma regular un modelo de información del
negocio y definir los sistemas apropiados para optimizar el uso de esta información .
Esto incluye el desarrollo de un diccionario corporativ o de datos que cont iene las
reglas de sintaxis de los datos de la organización , el esquema de clasificación de
datos y los niveles de seguridad. Este proceso mejora la calidad de la toma de
decisiones ge renciales asegu r ándose que se proporciona información confiable y
segura , y permite raci onali zar los re cursos de los sistemas de info rmación para
igualarse con las estrategias del negocio. Este proceso de TI también es necesario
para incrementa r la responsabilidad sobre la integridad y seguridad de los datos y
para mejorar la efectividad y control de la informació n compartida a lo largo de las
aplicaciones y de las entidades.
• P03 Determinar la dirección tecnológica. La función de servicios de información

debe determinar la dirección tecnológica para dar soporte al negocio. Esto requiere
de la creación de un plan de infraestructura tecnológica y de un consejo de
arquitectura que establezca y admin istre expectativa s realistas y claras de lo que la
DIRECCIÓN Y GESTIÓN DE PROYECTOS T IC 111

tecnología puede ofrecer en términos de productos, serv1c1os y mecanismos de

aplicación. El plan se debe actualizar de forma regular y aba r ca aspectos tales
como arquit ectura de sistemas , dirección tecnológica, planes de adquisición,
estándares , estrategias de migración y contingencias. Esto permite con t ar con
respuestas oportunas a cambios en el ambiente competitivo, economías de escala
pa ra consecución de persona l de sistemas de información e inversiones, así como
una inte roperabi lidad mejorada de las plataformas y de las aplicaciones .
• P04 Definir los procesos, organización y relaciones de TI. Una organización de TI

se debe definir tomando en cuenta los requerimientos de personal, funciones,
delegación, autoridad , roles , responsabilidades y supervisión. La organización
estará incrustada en un marco de trabajo de procesos de TI que asegura la
transparencia y el control, así como el involucramiento de los altos ejecutivos y de
la gerencia del negocio. Un comité estratégico debe garantizar la vigilancia del
consejo directi vo sobre la TI , y uno ó más comités administrativos , en los cuales
participan tanto el negocio como TI , deben determinar las prioridades de los
recu rsos de TI alineados con las necesidades del negocio. Deben existir procesos , <
z
<
u
políticas administrativas y procedimientos para todas las funciones, con atención "'zw
específica en el cont r o l, e l aseguramiento de la calidad, la administ r ación de <
o
"'
w
riesgos , la seguridad de la información , la propiedad de datos y de sistemas y la "'
:;
segregación de tareas. Para garantizar el soporte oportuno de los requerimientos "'
<
....
¡¡¡
del negocio , TI se debe involucrar en los procesos importantes de decisión. "'>w
z
::>
• POS Admini strar la inversión en TI. Establecer y mantener un marco de trabajo para z
<>
;::;
administ rar los programas de inversión en TI que abarquen costos, beneficios , o<
z
:>
LL
pr i oridades dentro del p r esupuesto , un proceso presupuesta ! formal y
admin istración contra ese presupuesto. T rabajar con los interesados para identificar
y controlar los costos y beneficios totales dentro del contexto de lo s planes
estratégicos y tácticos de TI , y tomar medidas correct ivas según sean necesarias .
El proceso fomenta la sociedad entre T I y los interesados del negocio, facilita el uso
efectivo y eficiente de recursos de TI, y br inda transparen ci a y responsabilidad
dentro del costo total de la propiedad, la materialización de los beneficios de l
negocio y el retorno sobre las inversiones en T I.
• P06 Comunicar las aspiraciones y la dirección de la gerencia. La dirección debe

elaborar un marco de trabajo de control empresarial para TI , y definir y comunicar
las política s . Un programa de comunicación continua se debe implantar para
articular la misión , los objetivos de servicio, las políticas y procedimientos, etc.,
aprobados y apoyados por l a di r ección. La comunicación apoya el logro de los
objetivos de TI y asegura la concientización y el entendimiento de los riesgos de
negocio y de TI. El proceso debe garant iza r el cumplimiento de las leyes y
reglamento s relevantes.

FUNIBER
• P07 Administrar los recursos humanos de TI. Adquirir, mantener y motivar una
fuerza de trabajo par a la creación y entrega de servicios de TI para el negocio. Esto
se logra siguiendo pr ácticas definidas y aprobadas que apoyan el re cl utami ento,
entrenamiento , la evaluación del desempeño , la promoción y la terminación. Este
proceso es crítico, ya que las personas son activos importantes , y el ambiente de
gobierno y de control interno depende fuertemente de la motivación y competencia
del personal.
• POS Administrar la calidad . Se debe elaborar y mantener un sistema de

administración de calidad , el cual incluya procesos y estándares probados de
desa rr ollo y de adquisic i ón. Esto se facilita por medio de la planeación,
implantación y mantenimiento de l sistema de administración de calidad,
proporc ionando requerimientos, procedimientos y políticas claras de calidad. Los
requerimientos de calidad se deben manifestar y documentar con indicadores
cuantificables y alcanzables. La mejora continua se logra por medio del constante
monitoreo , corrección de desviaciones y la comunicación de los resultados a los
interesados. La administración de calidad es esencial para garantizar que TI está
dando valor al negocio, mejora continua y transparencia para los interesados.
• P09 Evaluar y administrar los riesgos de TI. Crear y dar mantenimiento a un marco
<
;;: de trabajo de administración de riesgos. El marco de trabajo documenta un nivel
<
;¡; común y acordado de riesgos de TI, estrategias de mitigación y riesgos residuales
~
=:
z aco r dados. Cualquier impacto potencial sob r e las metas de la organización ,
:::>
z
-~ causado por algún evento no planeado se debe identificar, analizar y evaluar. Se
u
<
e
z deben adopta r estrategias de mitigación de riesgos para minimizar los r iesgos
:>
u..
residuales a un ni vel aceptable. El resu ltado de la evaluación debe ser entendible
para los participantes y se debe expresar en términos financieros , para permitir a
los participantes alinear los ri esgos a un nivel aceptable de tolerancia.
• P01 O Adm inistra r proyectos. Establecer un programa y un marco de control

administ rativo de proyectos para la administración de todos los proyectos de TI. El
marco de trabajo debe garantizar la cor r ecta as igna c ión de prioridade s y la
coordinación de todos los proyectos. El ma rco de t r abajo debe incluir u n plan
maestro , asignación de recursos , defin ición de entregables , aprobación de los
usuarios, un enfoque de entrega po r fases , aseguramiento de la calidad , un plan
formal de pruebas, revisión de pruebas y revi sión post-implantación después de la
implantac ión pa r a garant iza r la admin istración de los riesgos del proyecto y la
ent r ega de valor para el negocio. Este enfoque reduce el riesgo de costos
ine s p erad o s y d e cancelación de proye c tos , mejora la comunicación y el
involucrami ento del negocio y de los usuarios f inales, asegura el v alor y la calidad
de los entregables de los proyectos, y maximiza su contribuc ión a los programas de
invers ión en TI.
DIRECCIÓ N Y GESTIÓ N DE PROYECTOS TI C 113

FUNIBER
b) Adquirir e Implementar {Al)
Para materializar la estrategia TI , las soluciones T I necesitan ser identificadas ,

desarrolladas o adqu iridas , como asimismo es necesar io implementarlas e integrarlas a
las procesos de negocios. Adicionalmente , todo sistema requ ie re de cambios y
mantenimiento pa ra asegurarse que durante su operación continua satisfaciendo los
requerimientos del negocio. Para este dom inio surgen las preguntas:
• ¿Los nuev os proyectos tienen el potencial para entregar soluciones que satisfag an
las necesidades del negocio?
• ¿Es factible que los nuevos proyectos se ej ecuten de acuerdo a los plazos y
presupuest os conve nido s?
• ¿Los nuevos sistemas operaran adecuadamente una vez implementados?
• ¿Los cambios podrán hacerse sin poner en riesgo la operación del negocio?
<
z
Este dom inio considera los procesos: ..,<
E
>:
<
o
• Al1 Identificar soluciones automatizadas . La necesidad de una nueva aplicación o "
w
"'<
función requiere de análisis antes de la compra o desarrollo para garantizar que los
"<
requ isitos del negocio se satisfacen con un enfoque efectivo y eficiente. Este t:
""'
~
proceso cubre la definición de las neces idades, cons idera las fuentes alternativas, z
::;¡
realiza una revisión de la factibilidad tecnológ ica y económica , ejecuta un análisis z
o
u
de riesgo y de costo-beneficio y concluye con una decisión final de desarrollar o <
o
z
comprar . Todos estos pasos permiten a las organizaciones minimizar el costo para "
"-
adquirir e implant ar soluciones , mientras que al mismo tiempo facilitan el logro de

los objetivos del negocio .
• Al2 Adquirir y mantener software aplicativo. Las aplic aciones deben estar
disponibles de acuerdo con los requerimientos del negocio. Este proceso cubre el
d iseño de las aplicaciones , la inclusión apropiada de controles aplicativos y
requerimientos de seguridad, el desa rrollo y la configuración en sí de acuerdo a los
estándares. Esto permite a las organizaciones apoyar la operatividad del negocio de
forma apropiada con las ap licaciones automatizadas correctas.
• Al3 Adquirir y mantener infraestructura tecnológica. Las organizaciones deben

contar con procesos para adquirir , implantar y actualizar la infraestructura
tecnológica. Esto requi ere de un enfoque planeado para adquirir, mantener y
proteger la infraestructura de acuerdo con las estrategias tecnológicas convenidas
y la disposición del ambiente de desarrollo y pruebas. Esto garantiza que exista un
soporte tecnológ ico cont inuo para las aplicaciones del negocio .
114 DIRECCIÓN Y GESTION DE PROYECTOS TI C

FUNIBERff liiiiiiiiiiiiiiiiiiii¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡liiliiilllliliiiiiiii;;:mia::am:m::1:;;m;;;:;
• Al4 Facilitar la operación y el uso . El conocimiento sobre los nuevos sistemas debe
estar disponible. Este proceso requiere la generación de documentación y manuales
para usuarios y para TI , y proporciona ent re namiento para garantizar el uso y la
operación co rre ctos de las aplicaciones y la infraestructura.
• AIS Adquirir recursos de TI. Se deben suministrar recursos TI , incluyendo personas,

hardware , software y servicios. Esto requiere de la definición y ejecución de los
procedimientos de adquisición , la selección de proveedores, el ajuste de arreglos
contractuales y la adquisición en sí. El hacerlo así garantiza que la organización
tenga todos los recursos de TI que se req uieren de una manera oportuna y rentable.
• Al6 Administrar cambios. Tod os los cambios , incluyendo el mantenimiento de

emergencia y parches , rel acionados con la infraestructura y las aplicaciones dentro
del ambiente de producción, deben administrarse formalmente y controladamente.
Los cambios (incluyendo procedimientos, procesos, sistema y parámetros del
servicio) se deben registrar, evaluar y autorizar previo a la implantación y re visa r
contr a los r esul t ados planeados después de la implantación. Esto garantiza la
reducción de riesgos que impactan negati vamente la estabilidad o integridad del
ambiente de producción .
• Al7 Instalar y acreditar soluciones y cambios . Los nuevos sistemas necesitan esta r
funcionales una vez que su desa rr o ll o se completa. Esto r equ ier e pruebas
adecuadas en un ambiente dedicado con datos de prueba relevantes, definir la
transición e instrucciones de mig ración , planear la liberación y la transición en sí al
ambiente de producción , y revisar la postimplantación. Esto garantiza que los
sistemas operacionales estén en línea con las expectativas convenidas y con los
resultados .
e) Proveer y Soportar (DS)
Este dominio tiene que ver con la entre ga de los serv1c1os que son requeridos, esto
incluye: la provisión del servicio, la gest ión de seguridad y continuidad, el soporte a los
usuarios , la administ ración de los dat os y la gestión de las instalaciones de plat aforma
tecno lógica. Para estos efectos es necesario formularse las preguntas sigu ientes:
• ¿Se están proveyendo los servicios TI de acuerdo con las prioridades del negocio?
• ¿Están los costos de TI optimizados?
• ¿Está en condiciones la fuerza de trabajo de utilizar los sistemas TI

productivamente y con seguridad?
• ¿Se maneja adecuadamente la confidencialidad , integridad y disponibilidad de los

sistemas TI?
DIRECCIÓN Y GESTIÓ N DE PROYECTOS TI C 115

Este dominio considera los procesos:
• DS1 Definir y administrar niveles de servicio. Contar con una definición

documentada y un acuerdo de servicios de TI y de ni veles de servicio, hace posible
una comunicación efectiva entre la gerencia de TI y los clientes de negocio
respecto de los servicios requeridos. Este proceso también incluye el monito reo y la
notificación oportuna a los pa rticipantes sob re el cumplimiento de los nive les de
serv i cio. Este proceso permite la alineación entre los se r vicios de TI y los
requerimientos de negocio relacionados.
• DS2 Administrar los servicios de terceros . La necesidad de asegurar que los

servicios provistos por terceros cumplan con los requerimientos del negocio,
requiere de un proceso efecti vo de administrac ió n de terceros. Este proceso se
logra por medio de una clara definició n de roles, responsabil idades y expectativas
en los acuerdos con los terceros , así como con la re visión y monitoreo de la
efectiv idad y cumplimiento de dichos acue rdos. Una efectiva administración de los
se rvicios de terceros minimiza los riesgos del negocio asociados con proveedores <
z
<
que no se desempeñan de forma adecuada. ~
:;¡
>:
<
o
• DS3 Administrar el desempeño y la capacidad. La necesidad de administrar el :;¡
"'
desempeño y la capacidad de los recursos de T I requiere de un proceso para revisar
periódicamente el desempeño actual y la capacidad de los recursos de TI. Este
proceso incluye el pronóstico de las necesidades futuras , basadas en l os
requerimientos de ca rga de trabajo , almacenamiento y contingencias. Este proceso
brinda la seguridad de que los r ecursos de información que soportan los
requerimientos del negocio están disponibles de manera continua.
• DS4 Garantizar la continuidad del servicio. La neces idad de brindar continuidad en

los servicios de TI requ iere desarrollar, mantener y probar planes de continuidad de
TI, alm acenar respaldos fuera de la s instalaciones y entrenar de forma periódica
sob re los planes de continuidad. Un pro ces o efectivo de continuidad de servicios ,
minimiza la probabilidad y el impacto de interrupciones mayores en los se rvicios de
TI, sob re funciones y procesos claves del negocio.
• DS5 Garantizar la seguridad de los sistemas . La necesidad de mantener la

integridad de la información y de proteger los activos de TI , requiere de un proceso
de administración de la seguridad. Este proceso inc lu ye el establecimiento y
m anten imiento de roles y responsabilidades de seguridad , po lít icas, estándares y
procedimientos de TI. La adm ini strac ión de la seguridad también incluye realizar
monitoreos de segu ri dad y pruebas periódicas así como realizar acciones
cor rectivas sobre las debil idades o incidentes de seguridad identificados. Una
efectiva administ raci ón de la seguridad protege todos los acti vos de TI para

FUNIBERÍ~
GESTIÓ N DE PROYECT OS
..:amlli:mllll111211i;:;;;;¡¡¡;---;;;¡;¡¡¡¡;~;:¡¡;¡;;¡;;¡;:;¡¡==================::::;:::::J
minimizar el impacto en el negocio causado por vulnerabilidades o incidentes de

segu ridad.
• DS6 Identificar y asignar costos. La necesidad de un sistema justo y equitativo

pa ra asignar costos de TI al negocio, requiere de una medición precisa y un acuerdo
con los usuarios del negocio so bre una asignación justa. Este proceso incluye la
construcc ión y ope ración de un sistema para capturar, distribuir y reportar costos
de TI a los usuarios de los se rvicios. Un sistema equitativo de costos permite al
negocio toma r decisiones más informadas respectos al uso de los serv icios de T I.
• DS7 Educar y entrenar a los usuarios . Para una educac ión efectiva de todos los
usuarios de sistemas de TI , incluyendo aquellos que se encuentran dentro de TI , se
requieren identifi ca r las necesidades de entrenamiento de c ad a grupo de usua rios.
Además de identificar las necesidades, este proceso inclu y e la definición y
ejecución de una estrategia para llevar a cabo un entre namiento efectivo y para
medir los resultados . Un programa efectivo de entrenam ie nto incrementa el uso
efectivo de la tecnología al disminui r los errores, incrementando la productividad y
<
z
- oportuna y efectiva a las consultas y problemas de los usuarios de TI , requiere de
¡;;
~
::.z una mesa de servicio bien diseñada y bien ejecutada , y de un proceso de
:::>
z
administración de incidentes. Este proceso inclu ye la creación de una función de
·O
u
<
mesa de servicio con registro, escalamiento de incidentes, análisis de tendencia ,
o
z
:>
u.
análisis causa-raíz y resolución. Los beneficios del negocio incluyen el incremento
en la productividad gracias a la resolución rápida de consultas . Además , el negocio
puede identificar la causa raíz (tales como un pobre entrenamiento a los usuarios} a
través de un proceso de report e efectivo.
• DS9 Administrar la configuración. Garantizar la integ ridad de las configu rac iones de
hardware y software requ iere establecer y mantene r un repositorio de
configuraciones completo y preciso. Este proceso incluye la recolección de
información de la configuración inicial, el establecimiento de normas, la verificación
y auditoría de la información de la configuración y la actualización del reposit or io de
configuración conforme se necesite. Una efectiva administración de la
configuración facilita una mayor disponibilidad , minim i za los problemas de
producción y resuelve los problemas más rápido.

FUNI BER
• OS 1 O Administración de problemas . Una efectiva administ ración de problemas

requiere la identif icación y clasificación de prob lemas , el análisis de las causas
desde su raíz, y la reso l ución de problemas. El proceso de administración de
problemas t am bién incl uye la identificación de recomendac iones pa ra la mejora , el
mantenimiento de regist ros de problemas y la revisión del est atus de las acciones
correctivas. Un efecti vo proceso de administración de pro bl em as m ejo r a los niveles
de se rvicio, red u ce costos y mejora la convenien cia y sat isfacción de l usuar io.
• OS 11 Adm inistración de datos. Una efectiva administ ració n de datos requiere de la

identificación de requerimientos de datos . El p r oceso de administración de
información también incluye el establecimiento de procedimientos efectivos para
administrar la librería de medios, el respaldo y la recuperac ión de datos y la
eliminación apropiada de medios. Una efectiva administración de datos ayuda a
garantizar la calidad, opo rtunidad y disponibilidad de la informac ión del negoc io.
• OS 12 Administración del ambiente f ísico . La protección del equipo de cómputo y

del personal, r equiere de instalaciones bien diseñadas y bien administradas. El
<
z
proceso de administrar el ambiente fís ico inc luye la definición de los requerimientos :
<
o
diseño de procesos ef ecti vos para mo nito rear factores ambientales y administrar el .
o:
w
acceso físico . L a adm i nistrac ión efectiva de l ambiente f ísico r educe las
interrupciones del negoc io ocasionadas por daños al equipo de cómputo y del
personal.
• OS 13 Administración de operaciones . Un procesamiento de información completo y

apropiado requiere de una efectiva administración del procesamiento de datos y del
mantenimiento del hardware. Este proceso incluye la definición de políticas y
procedimientos de ope ración para una administr ación efectiva de l procesamiento
programado , protección de datos de salida sensitivos, monitoreo de infraestructura
y mantenimiento preventi v o de hardware . Una efectiva administración de
operac iones ayud a a mantener la integ ri dad de los datos y reduce los retrasos en el
t ra bajo y los cos t os operativos de TI.
d) Monitorear y Evaluar (ME)
Todo s los procesos T I necesitan peri ódicamente que se verifique mediante controles su
c alidad y conformidad. En este dominio se t r atan la gestión del rend imiento , el
monitoreo de los controles internos, la regulaciones que tiene que ve r la conformidad y
la gobernabilidad. Las preguntas típicas de este dominio son:
• ¿Los sistemas de med ició n de rendim iento de las TI permiten detectar a t iemp o los
problemas?
• ¿La gestión asegura que los controles internos son efectivos y eficientes?
118 D IRECCIÓ N Y GESTIÓ N DE PROYECTOS TIC

G ESTIÓN DE PROY ECTOS
• ¿Puede el rendimiento de las TI relacionarse con los objetivos de negocios?
• ¿Están siendo medidos e informados los riesgos, el control, la conform idad y el

rendimiento?
Este dominio consi dera los siguient es procesos:
ME1 Monitorear y evaluar el desempeño de TI. Una efectiva administración del

desempeño de TI requiere un proceso de monitoreo. El proceso incl uye la definición de
indicadores de desempeño relevantes, reportes sistemáticos y oportunos de desempeño
y toma r medidas expeditas cuando existan desviaciones. El monitoreo se requiere para
garantiza r que las cosas correctas se hagan y que estén de acuerdo con el conjunto de
direcciones y políticas.
ME2 Monitorear y evaluar el control interno . Establecer un programa de control interno

ef ectivo pa ra TI requiere un proceso bien definido de monitoreo. Este proceso incluye el
monito r eo y el r eporte de las excepciones de control, resultados de las auto-
<
z
<
~ evaluaciones y revisiones po r pa rte de terceros. Un beneficio clave del monitoreo del
~
>:
<
contro l interno es propo rcionar segu r idad respecto a las ope r ac iones eficientes ,
o
..::; ef ectivas y el cumplimiento de las leyes y regulaciones aplicables .
<
°'
<
¡...
¡¡¡ ME3 Garantizar el cumplimiento regulatorio. Una supe rvisión efectiva del cumplimiento
~
>
z regulatorio requie re del establecimiento de un proceso independiente de revisión para
:::>
z
-o garantizar el cumpl imiento de las leyes y regulaciones. Este proceso incluye la definición
u
<
o
z
de un estatut o de aud ito ría, independencia de los auditores , ética y estándares
:>
u.
profesionales , planeación , desempeño del t rabajo de audito ría y reportes y seguimiento
Q
a las actividades de auditoría. El p r opósito de este p r oceso es proporcionar un
aseguramie nto positivo re lativo al cumpli m iento de TI de las leyes y regulaciones.
ME4 Proporcionar gobierno de TI. El establecimiento de un marco de trabajo de

gobierno efectivo, incluye la definición de estructuras, procesos , liderazgo, ro les y
responsabilidades organizacionales para garantizar así que las inversiones empresariales
en TI estén alineadas y de acue rd o con las estrategias y objetivos empresariales.

G EST IÓN DE PROYECTOS
2.5 .3.2 Modelo de madurez
El modelo de madurez planteado por COBIT pe r mite establecer cual es el nivel de

desarrollo que tiene el proceso en la o r ganización. Para esto define 6 niveles, a
continuación se describen cada unos de estos niveles de madurez definidos po r
COBIT 33 .
• Inexistente - Se carece totalmente de un proceso. La organización no ha reconocido

la necesidad.
• Inicial - Existe evidencia que la organización ha reconoc ido la necesidad del

proceso. No ex iste un proceso formal estandarizado, si no que existe enfoques ad-
hoc que se aplican de manera individual o caso a caso. La gestión del mismo es
desorganizada.
• Repetible - El proceso se encuentra en un nivel de desarrollo tal que distintas

personas ej ec u tan más o menos los mismos p rocedimientos. No existe una
<
z
comunicación ni entrenamiento formal de los procedimientos, y la responsabilidad <
~
o:
se mantiene individual. Existe una gran dependencia del conocimiento q ue tiene los z
<
o
o:
individuos y, por tanto existe una probabilidad de erro r impo rt ante. w
<O
<
a:
• Definido - El proceso esta estandarizado , documentado y difundido mediante <
....
entrenamiento. Sin emba rgo, se deja a volunt ad de los individuos la aplicación de "'..,o:
>
z
los procedimientos del p r oceso y es poco probable que se detecten l as ::;¡
z
~
desviaciones en su uso. Los procedimientos en sí no son sofisticados y u
<
o
z
corresponden a la formalización de las prácticas existentes . :>
"-
Q
• Gestionado - Es posible monitorear y medir la conformidad en la aplicación de los
procedimientos del proceso y es posible tomar acciones cuando el proceso no está
operando adecuadamente. Los p rocesos están mejorándose con t inuamente. Se
dispone de automatizaciones y de herramien t as que son usadas de una manera
limitada o fragmentada .
• Optimizado - El proceso ha sido refinado al nivel de las mejores prácticas , basado

en los resultados del mejoramiento continuo y de los mode los ya maduros de otras
compañías. Las TI son usadas integralmente para automatizar los flujos de trabajo
entregando herramientas que mejoran la calidad y efecti v idad aumentando la
capacidad de adaptación de la organización .
33. !SACA. COBIT framevvork for IT Govemance and Control.

Enlace web: _ ~,,-;>~~~sa~c-a.~o~rg_;~K~ºº~·~eJ....,o._..·~-C~e~r~tP~r~c~o~b1~t~P-ag..,e~s~!O~\-E~rv~re~:~a~s~px
r ...
1 20 DI RECCIÓ N v GESTIO N DE PROYECTOS TIC

FU N1BE R í~ ----------------·G-ES·Tl·Ó·N.ºE·P-RO·Y-
EC.TO-S
2.5.3.3 Alca nces de COBI T
COBIT claramente es un marco de referenc ia para profesionalizar el área informática de

una organización q u e cuenta con capacidades propias o terciarizadas para la
implementación de proyectos típicamente soportados con ERP de clase mundial, que
tie ne un área de operación con varias decenas de servidores que dan servicios a más de
una locación, y que cuenta con áreas de mantenimiento y soporte. Y, más importante
los Sistemas Informáticos son reconocidos por el directorio como un componente clave
en el éxito come r cial de la compañía y, po r lo mismos que implican riesgos para el
negocio 34 .
Para controlar cualquier proceso es necesario contar con un mecanismo de medición ,

uno de detección de desviaciones y otro de rect ificación de las desv ia ciones.
Naturalmente la Gobernabilidad TI p lantea estos mecanismos y en concreto COB IT
plantea un modelo al respecto. Sin emba rgo, todo mecanismo de control tiene su costo ,
requiere personal entrenado en el área de info rm ática, auditores, consultores externos y
<
z
<
~
nuevos element os a conside rar en los diseños e implementación de procedimientos y
e¡
::;:
<
software .
o
::¡
"'
< COBIT es técnicamente posible de aplicar en toda área de In formática de cualquier
a:
~
empresa mediana hacia arriba, pero su costo de implementación solo se justif ica si el
"'::¡
=:
z
di rectorio tiene poderosas razones para ello: por ejemplo la Sarbanes - Oxley , acuerdos
de accionistas, regulaciones propias de cada país , etc. 35
::::>
z
'!'?
u
<
o
5
u.
2.5.4 BENCHMARKING COMO MEDIO DE ENCONTRAR PRÁCTICAS
La palabra benchmark es un ang licismo traducible al castellano como comparativa.
En la práctica , el benchmarking es un proceso de compa ración riguroso cuyo fin es

medir el rendimiento de un sistema o componente de un sistema.
Consiste en comparar componentes con relación a una práctica estándar o un modelo

patrón. Sino existe, la comparación permite extraer aquellos componentes que son
estándar. El resultado se considera un marco de referencia , es decir el benchmarking
analiza varios sistemas en base a sus componentes y extraer aquellos que responden a
los objetivos deseados , son los más exi tosos o simp l emente son destacados y
34. SAFFIRIO, MARIO. (2007). la COB!T y la organización del área informática. Marzo, 3.
Enla ce web: http· msaff1rjo.wordpress.coml200?/03 '03,'la-cob1t-v-12-orgar, ac1on-del-area - dormatica
35. !bid.

G ESTIÓ N DE PROYECTOS
FUNIBER
ejemplificadores. El conjunto de componentes seleccionados dan forma a un marco de

referencia usado para patrón futuro de comparación.
En el mundo de la gestión , el benchmarking es una herramienta amp liamente utilizada

para encontrar patrones o modelos de referencia. El riesgo es lo que es v ál ido para un
caso no es válido para otros.
En e l caso de la determi nación de buenas prácticas, un estudio de benchmarking

permite extraer de va rios casos destacados aquellas prácticas exitosas , que luego deben
ser adaptadas cada situación posterior donde se v ayan a aplicar.
2 .5.5 MARCOS DE REFERENCIAS VERSUS CMMI
El uso de mode los de madurez y marcos de referencia obedece siempre al deseo de

acercar a los departamentos de Tecnología a los mismos niveles y exigencias de ca li dad
y servicio que se le pide a cualquier función o línea de negocio de una empresa. El
problema rad ica en que por el enfoque de Modelos de Madurez y de Marcos, no existe
uno lo suficientemente completo para satisfacer toda la complejidad de la gestión
tecnológica y de la dinámica organizacional. Por ello, muchas empresas cons ideran que
los enfoques subyacentes en Modelos de Madurez y Marcos no son exc luyentes, sino
complementarios . La siguiente tab la ejemplifica esta situación complementando el
CM M 1 con los marcos de referencia re visados, pero dejando claro que todos se
complementan entre sí.

Fu N1BE R ~~ f - - - - - - - - - - - - - - - - ·G•EliilSTiiiil!ÓliiiN.ºE_P_RllOY.
EC. TO
-S
ITTL COBiT SGSI
mL es una recopilación de una COBiT es un conjunto de SGSI es un conjunto de procesos

serie de mejores/buenas prácticas indicaciones (buenas prácticas) que pretenden gestionar de
en diferentes sectores de actividad para reducir la brecha entre los manera eficiente el acceso a la
a nivel mundial, que se publican de requerimientos de control, los información, buscando minimizar
forma aplicada y sistemática, con asuntos técnicos/ tecnológicos y los riesgos de seguridad en base a
el objetivo de lograr una gestión los riesgos de un negocio/empresa. criterios de conftdencialidad,
eficiente de la infraestructura y los COBiT verifica la conformidad de integridad, y disponibilidad de los
servicios de TI . las actividades TI en cuanto a activos de información.
illl permite lograr efectividad y disponibilidad, rendimiento, SGSI permite lograr confianza en
.
eficiencia en las actividades TI.
La principal ventaja de mL
es que ha demostrado su
eficiencia, y riesgos asociados de
los servicios ofrecidos con relación
a los objetivos y estrategia de una
la seguridad de Ja información a
.
nivel organizaoonal.
La principal ventaja es que
.
eficacia con su enfoque a la
gestión de servicios de TI.
El gran problema de mL es
.
empresa.
La principal ventaja de COBiT
es que proporciona un
una vez implantado se
mejora competitividad e
Imagen, al mostrar
que no cubre adecuadamente ambiente de regulación de mecanismos más seguros de
las fases de desarrollo de las actividades ligadas a la control de acceso a la
software ni la gestión de
proyectos asociada a esa fase
de construcción de activos de
gestión de tecnología y con
orientación clara al alcance
de los objetivos de negocio.
. información.
El gran problema es poder
liderar un proyecto
software. Esto lo consigue generando tecnológico aglutinando a las
un lenguaje común a todos otras funciones o
los involucrados en el control departamentos de un
. de procesos.
El gran problema es su
implementaciÓn, pues debe
empresa, y en concreto al
imponer medidas de
seguridad.
<
z superarse problemas de
<
~ condentizar a la Alta
o:
Dirección, generar una
z
< estructura de toma de
oo: decisiones, monitorear las
~ inversiones, gestionar
::!: riesgos, etc.
o:
<
.... CMMI CMMivs. ITTL CMMI vs. COBiT CMMI vs. SGSI
Vi
..,
o:
> CMMI es una fusién de modelos Son dos enfoques Son dos enfoques Son dos enfoques
z
::> de mejora de procesos para complementarios. Al analizarlos complementarios. Al analizarlos complementarios. Al analizarlos
z ingeniería de sistemas, se observa observar que CMMI se se aprecia claramente que CMMI se muestra que SGSI aporta
~ elementos de gestión de riesgos
u ingeniería del software, centra en garantizar la calidad en opera sobre el desarrollo de
< software o en portafolios de que completan las exigencias de
o
z
desarrollo de productos el desarrollo de los proyectos de
::>
u..
integrados y adquisición de software, mientras que mL proyectos informáticos, mientras CMMI. Mientras CMMI aporta
software. garantiza la explotación del que COBiT permite el monitoreo, grandes lineamientos de gestión
CMMI garantiza la cahdad de un producto de software control y balance entre la de riesgos propios del desarrollo
desarrollo de software o (mantenimiento). Mientras CMMI estrategia de negocio (que en de software o de los proyectos
.
proyecto informático.
La gran ventaja de CMMI
es que ha demostrado ser
ayuda a conseguir aplicaciones de
calidad, illl, permite administrar
la infraestructura TI asociadas a las
suma define el portafolio de
proyectos a realizar/ ejecutar) y la
utilidad de las aplicaciones en el
Informáticos, SGSI permite contar
con mecanismos de seguridad de
la información aplicables a los
una metodología de gran aplicaciones y a las mismas negocio. Mientras CMMI ayuda a software o aplicaciones
eficacia, que ha permitido aplicaciones. Se puede decir que consegui r aplicaciones de calidad, resultantes. Se puede decir que
mejoras de gran Impacto incluso prácticas illl pueden COBiT permite alinear las las indicaciones de SGSI
en procesos de desarrollo integrarse en CMMI para preparar aphcac1ones con los objetivos introducen en CMMI mecanismos
de productos software, acciones de mantenimiento de las estratégicos. Se puede decir que de seguridad de la información
tales como reducción del aplicaciones. las prácticas de COBiT engloban al que deben ser considerados en
coste de desarrollo, CMMI en el sentido de mostrar el un desarrollo o proyecto.
localización y resolución de fin de negocio de los proyectos
. defectos, entre otras.

El gran problema de CMMI
es su falta de adecuación
informáticos y de los desarrollos
de software.
al enfoque a servicio que

está experimentando el
sector de las TI en todas
sus líneas de actividad, así
como el alto esfuerzo de
implantación que exige.
Tabla 2.10. CMMI versus Marcos de Referencia.
DI RECCIÓN Y GESTIÓN DE PROYECTOS T IC 123

G ES TIÓN DE PR OYE CTOS
FUNIBER
2.6.1 DESCRIPCIÓN
PRojects IN Controlled En vironments (PRINCE), o 'proyectos en entornos contro lados',

es un método de ges ti ón de proyectos que cubre la adm i nist r ación , contro l y
organización de un proyecto. PRINCE2 es una marca registrada de la OGC del Reino
Unido. PRINCE2 fue originalmente desarrollado por la CCTA 36 que actualmente forma
parte o fue absorbida por la OGC 37 . Desde 1989 se viene usando como un estándar
para la gestión de proyectos sobre todo en el Reino Unido. Este método fue inicialmente
desa rro llado únic amente para proyectos TI C .
38
Prince2 es un método basado en procesos para la gestión efectiva de proyectos. Sus
rasgos esenciales son:
<
z
• orientación a la justificación de negocios; :
<
• estructu ra organizacion al bien definida de para el equipo de gestión de proyectos; o
~
• enfoque de planificación basado en el producto ; :'!
o:
<
¡¡;
• enfatiza la división del proyecto en fases o estados gestionables y controlables; e, ¡:¡
~
z
:::>
z
• introduce niveles de flexibilidad ad-hoc al proyecto o sus fases/estados. o
V
<
o
z
:::>
l...
El desarrollo de PRINCE2 desde PRINCE fue el resultado de mejoras ba s adas en
"'
u s uario s, especialistas en gest ión de proyectos y un grupo de 1 50 organizaciones
públicas y privadas. El resultado es una herramienta de buenas prácticas genéricas lo
suficientemente flexibles para ser adaptada a cada organización y ser compatib le con
cualquier tipo de proyecto.
2.6.2 PRINCE2 VERSUS PM BOK
PRINCE2 y PMBOK son:
• compatibles y complementarios, armonizan entre ellos;
• no son excluy ent es ni inc apaces de coe xistir ;
36. CCTA: Central Computer and Telecommunications Agency.

37. OGC: Office of Government Commerce. Oficina independiente del Tesoro Británico.
38. Prince2. En lace web: -; :J • .•. o~·-,c<>2 corr .:be·~~::.: ;sn
PRI NCE2. Enlace web: •·-:0:1 .w,.w ormce-oEjc.aisit<> cor

• no compiten entre sí;
• su combinación mejora calidad de productos y servicios prestados, y mejora la

satisfacción de los clientes;
• ambas tienen su propio sistema y mecanismo de certificación; y,
• su uso integrado aún está en manos del juicio profesiona l, y la experiencia en

proyectos.
PRINCE2 PMBOK
Proyecto es un entorno de gestión que se crea con el Proyecto es la planificación consistente en un

propósito de entregar uno o más productos de negocio conjunto de actividades que se encuentran
de acuerdo a las particularidades de un negocio interrelacionadas y coordinadas. La razón de un
específico. Este entorno de gestión es temporal para la proyecto es alcanzar objetivos específicos dentro de
vida de un proyecto dentro del cual se aborda o trata los límites que imponen un presupuesto, calidades
<
z
un problema único. El trabajo de desarrollo en el establecidas previamente y un lapso de tiempo
~ proyecto se asume que es menos seguro que el de previamente definidos. Un proyecto es un
~ mantenimiento (en el cual existen normalmente emprendimiento que tiene lugar durante un tiempo
:t
<
o procesos y procedimientos bien probados y utilizados). limitado, y que apunta a lograr un resultado único.
.
~
En el desarrollo hay un cierto grado de riesgo lo cual Surge como respuesta a una necesidad, acorde con
! requiere un entorno de gestión diferente a los la visión de la organización, aunque ésta puede
..."'<
¡;; procesos normales del día a día. desviarse en función del interés. El proyecto finaliza
~ cuando se obtiene el resultado deseado, desaparece
::z Las características de un proyecto PRINCE2 son: una
:::> vida finita y definida, productos de negocio definidos y la necesidad inicial, o se agotan los recursos
z
-O medibles, un conjunto de actividades para obtener los disponibles. PMBOK define un proyecto como un
ü
<
o productos de negocio, una cantidad definida de esfuerzo temporal que se lleva a cabo para crear un
z
::>
u.. recursos, y una estructura organizativa, con producto, servicio o resultado único.
responsabilidades definidas, para gestionar el
proyecto.
a. ALBERTCMZ. (2011). PRINCE2 o PMBoK: ¿Qué es mejor para gestionar mi p royecto?
Enlace web: http b1ogs sa 1eur .edu p•oiec~·maoagemen~ princd-y-pmbo~
A continuación diversas comparaciones entre PRINCE2 y PMBOK 39 .
39. Material extraído de material libre en internet de:

ÁGUEDA, ÁNGEL. ( 2010). Guia del PMBOK versus PRINCE2. PMI Spain Chapter.
En lace web: htto .1""'"' ~ deshare.ret,evercreenp;r ;;~oo~·vs-; .,ce2
ALBERTCMZ. (2011 ). PRINCE2 o PMBoK: ¿Qué es mejor para gestionar m i p royecto?
Enlace web: http: 1 blogs.s¡; eurl.ecfu!pro,ect-manage:nentiprjnct.2·y-prnbc.'
DI RECCIO N Y GESTIÓ N DE PROYE CTOS TIC 125

FUNIBER
PRIN~ Un poco de historia - .>

~ ~ PRINCE2
CCTApublica
PRINCE.
Simpact Systems Estándar de
desarrolla el gestión de
método de gestión proyectos de 21 edic ión
de proyectos SlfTI.
"\.~"
PROMPTll
1.97 5
'\.~9f>
31 ed ición
11 edición d e 51 ed ición
-
-i.979
PRINCE2.
CCTAadopta Orientada a
PROMPTll todo tipo de
para todos proyectos.
los proyectos
de TI.
<
z
:
<
Elaboración y o
~
Publicación de publicac1on de e>
documentos <
los resultados ;;;:
<
del proyecto ·Fundamentos !:::
ESA en la para la Guia del PMBOK. "'[!;
2 ' eoicion 4 1 edición >
revista Proiect d1rccc1on oc
Management proyectos ~ 3
z
Creación del
Jou•nal .,
"\.9t.f>· ~
u
o<
z
PMI
....
::>
1.969 2
'\.~'\.-
~~ Guia de1 PMBOK.
Guia del PMBOK 3 1 eoición
-i.9S'l. 11 ed1c1ón
Primeras
Se aprueba el cert1flcac10-
proyecto ESA nes PMP
para desarrollar
os
procedim1en1os y
conceptos de la
DP (Grupo ESA
Figura 2.37: Epígrafe Historia de PRINCE2 y PMBOK

GESTIÓN DE PRO Y ECTOS
Basado en buenas prácticas.
Para todo tipo y tamaño de proyectos.
Vocabulario común.
Roles y responsabilidades bien definidos. X
Centrado en los productos.
Gestión por excepción. X
Guiado por un Business Case más que en conseguir la terminación

X
del proyecto.
Asegura que las partes interesadas estén debidamente X

representadas en la planificación y en la toma de decisiones.
Tabla 2.11. Beneficios de PRINCE2 y PMBOK.

<
"'<
....
¡;;
e¡
~
z
::>
z
<>
v Una amplia colección de "buenas prácticas" para
C5
Un método de gestión de proyectos.
z gestión del proyecto.
::>
u..
No prescriptivo -7 Descriptivo Prescriptivo
Un conjunto integrado de pocesos y temáticas (no

Cada tema se puede consultar aisladamente de los
son silos aislados que se puedan aplicar
otros.
selectivamente).
Orientado a los Project Managers. Cubre todos los roles de gestión del proyecto.
Cubre las competencias interpersonales. No cubre las competencias interpersonales.
Hace referencias a las técnicas y explica PBS y

Describe las técnicas.
revisión de calidad.
Tabla 2.12. PRINCE2 vs PMBOK.

FUNIBER
Puesta en marcha de un proyecto.

Iniciación
Dirección de un proyecto.
Inicio de un proyecto.
Planificación Gestión de los límites de fase.
Gestión de la entrega de productos.
Control de una fase.

Ejecución
Gestión de la entrega de productos.
Dirección de un proyecto.
Seguimiento y control Control de una fase.
Gestión de los límites de fase.
Gestión de los límites de fase.

Cierre
Cierre de un proyecto.
Tabla 2.13. Procesos de PRINCE2 y de PMBOK. <

z
<
<
o:
<
Justificación continua de negocio.
Integración "'"'>u
Gestión por excepción.
z
::>
Alcance PBS vs WBS. z
-O
~
<
Plan de proyecto, plan de fase, plan de equipo, e.
z
Tiempo ::>
plan de revisión de beneficios. u.
Costos También EVM aunque no se explica.
Orientación de producto.
Calidad Lecciones aprendidas y mejora continua.
Gestión de la configuración.
RR.HH. Sólo definición de roles y responsabilidades.
Estrategia de gestión de la comunicación.

Comunicaciones
Más desarrollo en MSP.
Tabla 2.14. Áreas de Conocimiento de PRINCE2 y de PMBOK.
Similitudes entre PMBoK y PRINCE2 :
1 . Basadas en buenas prácticas.
2. Aplicables a proyectos de cualquier tamaño y sector.

FUNIBER~f .....................................................
3. Proveen de un v ocabulario común.
4. Se basan en conseguir los productos y no en real iza r las tareas o actividades.
Diferencias entre PMBoK y PRINCE2 :
1. PMBoK está orientado a project managers y PRINCE2 a toda la organización

que interviene en el proyecto .
2. PRINCE2 def ine con más detalle los roles y responsabilidades dentro del
proyecto y la organización de gestión y toma de decisiones.
3. PRINCE2 se basa en una gestión por excepción, donde la organizac1on de

proyecto permite que cada uno sepa lo que tiene que hacer y pueda tomar las
decisiones que le corresponden.
4 . PMBoK está orientado a la finalización del proyecto y PRINCE2 a la

consecución del Business Case.
<
5. PMBoK describe las técnicas que se usan al gestionar un proyecto mientras que
z
'<
~ 6. PMBoK incluye la gestión de adquisiciones mientras que el PRINCE2 no lo hace.
w
"'
<
o: 7. PMBoK incluye las habilidades de gestión e interpersonales mientras que
::: PRINCE2 no lo hace.
V>
"'>w
:5
z
!'!
u
<
e
z
::>
u..

GESTIÓ N DE PROYECTOS
LJ Resumen
<
~
u
"'
~
::r
<
o
!
"'
<
"'~
;;
!
>
z
::>
·~u
<
o
5
u.

Fu N1BE R ~ f - - - - - - - - - - - - - ·l· N·G· E·N·I E·R·i·A. º. E· S· O· F·T·W·A·R·E ·Y· G
· E·S·T·
IÓ·N
- D·E· P·R·O·YE· C·T·O·S
r
Ca 1
,
INGEN IE RIA DE ,
<
:¡
u
SOFTWARE Y GESTION DE
"'~
<
o
5
"'
PROY ECTOS
<
°'....;;:;
<
::;
>
z
::;)
z
-~
u
~\
<
o
z
::>
u.
- Conocer las dimensiones de un proyecto informático.
- Conocer las fases de desarrollo de un proyecto informático.
- Conocer los modelos de desarrollo de un proyecto informático.
Los proyectos informáticos son un tipo particular de proyecto, los cuales, según como
se mire , podrían ser proyectos industriales en la medida de producir un artefacto, o
podrían conside r arse proyectos de ingeniería en razón de buscar y crear soluciones
(proyect o de acción). No se quiere entra r en una discusión taxonómica , pero si se puede
afi rm ar que los proyectos informáti cos se distinguen por ser un universo por sí solos.

I NGENIER ÍA DE SO FTWAR E Y GESTI ÓN DE PROYECTOS
FUNIBER
Por este motivo y, como se ve rá más adelante, al ser pa rte de un proyecto e-Business,
este apartado se dedica a describir la complejidad inherente a un proyecto informático.
Como se ha visto con anterioridad , un proyecto só lo puede distinguirse por

singularidades y crite r ios, por este motivo, se discuten aquí tipos de proyectos
infor máticos según los siguientes criterios :
• dimensión del artefacto ;
• dimensión de alcance ;
• dimensión del trabajo ;
• dim en sión de desarrollo; y,
• dimensión organizacional.
3.1.1 SEGÚN DIMENSIÓN DEL ARTEFACTO <

z
<
u
~
"<
o
Esta dimensión cubre la naturaleza del principal producto físico a entregar, atendiendo a ~
~
la forma de la solución que se entrega . En este caso , puede ser un estudio y / o un
conjunto de componentes como:
• Informes sobre los beneficios de la solución informática.
• Software y sus versiones de desarrollo dispuestas en unidades de almacenamiento ,

en una o varias copias.
• Personal requerido para la operación del software según indicaciones de habilidades

y aptitudes.
• Documentación y manuales del software de diverso índole y natu ral eza

dependiendo de los lectores de tal material.
• TI asociadas al uso del producto material de software .
Lo anterior no evita que puedan d istinguirse dos tipos de proyectos: proyecto de

software y proyecto de infraestructura informática.
a) Proyecto de software . Este es el proyecto más común y se caracteriza por que

el producto es un software en algún soporte físico.
Según Alter un proyecto de software es un sistema de trabajo de tiempo

limitado que busca satisface r un requerimiento particular. Solucionar el
problema de Y2K es un ejemplo .

I NGENI ERÍA DE SOFTWARE Y GESTIÓN DE PROY ECTOS
El proyecto comienza con algún software existente y su objetivo es remover

problemas desde tal software sin cambiar su función pretendida. El objetivo es
hacer cosas que no cambian el medio externo, como por ejemplo, la nueva
versión de un procesador de textos donde el resultado d irecto puede ser un
software a bajar (download) o un parche, en lugar de hacer cambios en un
sistema informático operacional dentro de una organización particular.
El gestor de este tipo de proyectos , en este caso, declara una victoria cuando el
software corre en un ordenador de la manera deseada , independiente de quien
le esté usando.
Se debe recordar que el proyecto como ta l no existe, lo que se define como

proyecto son dos dimensiones que conforman una a la v ez : Dimens ión de
Gestió n y Dimens ión de Construcción.
Para gestionar un proyecto de software de la mejor manera hay que

comprender que puede ir mal , y co mo hacerlo bien . Existen d iez seña le s que
ind ican que un proyecto esta en riesgo:
<
z
No se comprende las necesidades del cl iente.

z Las necesidades del negocio cambian.
:::>
z
!'? Las fechas de entrega no son realistas.
u
<
o
z
::>
u.. Los usuarios se resisten.
Se pierden los patrocinadores.
Se carece de personal.
Los gestores evitan buenas prácticas y sabias lecciones.
Para evitar los problemas anterio rmente mencionados, se sugiere lo siguiente:
Empezar con el pie derecho, trabajar duro para comprender el problema a

tratar.
Mantenerse, proporcionar incentivos para conseguir una rotación de l

personal .
Segu imiento del progreso , el progreso se sigue mientras se realizan los

productos de trabajo (código fuente, especificaciones de trabajo , conjunto
de casos de prueba, etc.)
Tomar decisiones inteligentes, asigne mas tiempo del que pensaba necesitar
para tareas arriesgadas o complejas.
D IRECCIÓN Y GESTIÓN DE PROYECTOS TI C 135

I NGENIERÍA DE SOFTWAR E Y GESTI ÓN DE PROYECTOS
FUNIBER
Realizar un análisis después de haber termi nado el proyecto .
Los participantes de todo proyecto de software son los siguientes:
Gestores super iores: que definen los aspectos de negocios que a menudo
tienen una significati va influencia en el proyecto .
Gestores (t écnicos) del proyecto que deben planificar , motivar, organizar y

co ntro lar a lo s profesionales que realizan el t rabajo de software .
Profesionales que proporcionan las capacidades técnicas necesarias para la

ingeniería de un producto o aplicación.
Clientes que especifican los requ isitos para la ingeniería del software y otros
elementos que tienen menor influencia en el resultado.
Usuarios finales que interaccionan con el software una vez que se ha

entregado para la producción.
Un proyecto de software puede ser parte de un proyecto de sistema de

información o de un proyecto de un sistema de t r abajo (un sistema humano-
máquina de trabajo). Si es así, el esfuerzo no es completo hasta que finalmente
el proyecto de software opera como se pretende dentro del sistema de
info rma ción o el sistema de trabajo.
<
Dentro de esta definición tienen cabida todos los proyectos informáticos ;;¡
<
....
v inculados al diseño lógico, im plantación , etc. o cualquier otra actividad que
"'
~
finalmente conduce a software operando en hardware. ~
z
::>
b) Proyecto de infraestructura informática . Estos proyectos son poco frecuentes, ~

ü
e<
pero no por ello ausentes en esta dimensión . Estos proyectos, según Steiner, z
::>
u.
son casos especiales en que no hay necesariamente un desarrollo de software,
sino se encuentran caracterizados por la elección de hardware para una mayor
aplicación , consol idar servidores o red iseñar redes de telecomunicaciones.
3.1.2 SEGÚN DIMENSIÓN DE ALCANCE
Los proyectos pueden definirse en función del alcance pretendido . En este caso se
distinguen proyectos de sistemas de información y proyectos de ingeniería de software .
a) Proyecto de sistema de información . Según Alter un proyecto de sistema de

informac ión es un sistema de trabajo de tiempo limitado cuyo objetivo es crear
o modificar un sistema de información para que opere según un conjunto de
requerimientos y sea mantenible .
Un ejemplo de proyecto de sistema de información es construir un nuevo

sistema de seguimiento de ventas . La esencia del sistema de trabajo es vender,
pero el sistema de información le provee un soporte. El gestor de proyectos
136 D IRECCIÓN Y GESTJON DE PROYECTOS TIC

FU N 1BE R fj -------------·
I N·G·E·N·IE.R.ÍA·D·E·S·O·FT·W·A·R·E·Y-GE
· S·T·IÓ·N-Dll
E .P.RO·Y·E·C·TO·S·
declara la victoria cuando el sistema de info rmación está operando de la

manera deseada, independiente de si las ventas se hacen o no efectivamente.
Debe acla rarse aquí que sistema de información se entiende en un sentido

amplio, lo cual involucra entidades humanas e infraestructura TI . En este
sentido el sistema de info rmación se compone de un sistema informático ,
también llamado sistema de información basada en ordenador, apa rt e de un
sist ema no computacional.
Alter dist ingue aquí la visió n de TI (' IT vision ' ) y la visión de negocio (' business
vision').
a. Proyecto de sistema de información: visión de TI

Según Alter un proyecto de sistema de información, desde la visión de 11 es un proyecto cuyo
objetivo inmediato es construir o modificar software. La victoria se declara cuando el software
satisface requerimientos y es aceptado por los usuarios y/o sus directivos.
b. Proyecto de sistema de información: visión de negocios

Según Alter un proyecto de sistema de información, desde la visión de negocios, es un proyecto
cuyo objetivo inmediato es mejorar un sistema de trabajo. La victoria se declara cuando el sistema
<
z
<
de trabajo satisface objetivos de negocio y cuenta con un mecanismo para continuar cambios de
~ manera exitosa.
:::¡:
<
o
~
b) Proyecto de ingeniería de software . Según Thayer los proyectos de Ingeniería
!O
"'<
1-
de Software son frecuentemente partes de proyectos mayores que incluyen
¡¡;
::> equipamiento (hardware ), servicios (facil ities), personal y procedimientos.
z
::>
Ejemplos son sistemas de vuelo , sistemas de contabilidad, sistemas de radar,
z
o sistemas de control de inventarios y sistemas de control ferrovia rio.
ü
<
o
z
Thayer añade que este tipo de proyectos puede considerarse un proyecto de
"'
u.
r-
software cuando el producto del proyecto es un software ; aunque tamb ién
debemos considerar el software como producto y vehículo de entrega al mismo
tiempo.
3.1.3 SEGÚN DIMENSIÓN DEL TRABAJO
Aquí el proyecto se distingue por el tipo de trabajo a rea lizar sobre los materiales , el cual
puede ser a medida o una adaptación.
a) Proyecto para construir algo nuevo o a medida. Aqu í se elabora una solución
que se plasma en un software y/o infraestructura hecho a la med ida o nuevo.
Un ejemplo de este tipo es el desarrollo de un sistema de información para una
actividad organizacional específica o para un área vertica l de servicios como lo
es sanidad.
b) Proyecto de adaptación. Aquí se elabora una so lución que involucra la

adaptación de un software y/ o infraestructura . Por ejemplo, aqu í tienen cabida
los desarrollos de aplicaciones ERP que requieren adaptación de código fuente.

INGENIERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
FUNIBER
3 .1.4 SEGÚN DIMENSIÓN DE DESARROLLO
Esta dimensión permite caracterizar el proyecto según la actividad de desarrollo que se

ejecuta o el modelo de desarrollo que se sigue.
Las actividades son fases del desarrollo, las cua les se organizan u ordenan en procesos
descritos en la literatura como modelos o paradigmas 1 de desarrollo .
3.1.4.1 Fases de desarrollo
A continuación se describen las fases de desarrollo, para luego mostrar luego algunos
de los paradigmas o modelos más distintivos.
Las fases de desarrollo habituales o más frecuentes son:
a) Análisis de requerimientos;
b) Diseño;
c) Im plementa ción;
d) Prueba;
e) Entrega y Mantenimiento.
A continuación cada una de ellas se describe brevemente.
a.- Anális is de requerimientos
El análisis de requerimientos pretende re solver la pregunta ¿cuál es el problema?, o ' el

qué', cuya respuesta debe permitir identificar:
las fun ciones a desarrollar y el dominio de información a manejar;

las posibles ampliaciones;
el monto y tipo de documentación ;
las cara cte rísticas y funciones de desempeño , comportamiento, rendimiento y
las interconexiones lógicas; y,
el estudio de Factibilidad Técnico , Social , Eco nóm ico y Pol ítico.
l. Un paradigma de desarrollo de software o de sistemas de información, puede decirse, es un arquetipo o modelo de

ciclo de vida de un software, el cual sirve para construir un producto informático. Existen varias formas, en todas las
cuales cambia la forma de ejecutar etapas de análisis, diseño, construcción, programación y manutención.

I NGENI ERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
Descripción
del sistema
Modelo
de análisis
Modelo
de diseño
<
z
<
u Figura 3.1: Análisis como puente entra la ingeniería y el diseño de software.
a
:i:
<
o
~ Las tareas y document os (o info rmación) a generar son:
~
"',...<
¡;; Reconocer el Problema: necesidades, Alcance general , Plan del problema ,
!:>
Análisis de riesgos, Especificación d~I Problema.
:5
z
·O Evaluación y Síntesis: alcance detallado , Flujos de información, Restricciones ,
ü
<
e Prototipos.
z
::>
u..
Modelamiento del Proyecto: criterios de validación, de acuerdo a las
alternativas se escoge una y se realiza un modelamiento extens ivo sobre ella.
Especificación: modelamient o del sistema, donde se especifica todo lo que se
requiere.
Revisión : ajustes, det alles o errores , Necesidades nuevas del usuario, Ajustes
de calendarización de riesgos , Monitoreo y Control.
Puede dividirse en cinco áreas de esfuerzo:
• Reconocimiento del problema.
• Evaluación y síntesis.
• Modelado.
• Especificación.
• Revisión.

FUNIBER~~
I NGEN IERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
El modelo de análisis debe lograr tres objetivos primarios:
• Describir lo que requiere el cliente.
• Establecer una base para la c rea c ión de un diseño de software.
• Definir un conjunto de requisitos que se pueda va lidar una vez que se constru ye el
software.
Diagrama
Diagrama
de fluj o
entidad-relación
de datos
Diccionario
de datos
~
«
<
!::
"'
¡:¡
::z
=>
z
o
V
<
o
z
::>
u.
Figura 3 .2: Los elementos del modelo de análisis.
Podemos notar que en el centro se encuentra el d icc ionario de datos que es un almacén
que contiene defin iciones de todos los objetos de datos consumidos y producidos por el
software.
T res diagramas diferentes rodean al núcleo :
El diagrama de entidad-relación DER representa las relaciones entre los objetos de

datos, actividad de modelado de datos; los atr ibutos de cada objeto de datos se pueden
describir mediante una descripción de objetos de datos.
140 DIRECCIÓ N Y GESTIO N DE PROYECTOS TIC

FUNIBERÍ~ .........................................
I NGENIERÍA DE SOFTWARE Y GESTIÓN DE PROY ECTOS
El diagrama de flujos de da tos DFD sirve para:
• Proporcionar una indicación de cómo se transforman los datos a medida que se

avanza en el sistema.
• Representar las funciones que transforman el flujo de datos, proporcionan

información adicional.
El diagrama de transición de d atos DTE indica como se comporta el sistema como

consecuencia de sucesos externos.
b.- Diseño
El diseño es una fase intensiva en conseguir responder la pregunta ¿cuál es la solución?,

solución que se representa con detalle y precisión en un modelo del sistema que permita
ver de qué manera se resuelven los problemas del usuario. Básicamente se traducen los
requisitos de software a un conjunto de representaciones adecuadas a su posterior
programación en lenguaje de máqu ina.
La documentación incluye:
<
a:
< • Estructura de datos.
"'=
a:
> • Arquitectura del software.
"
:::>
"
·O
ü
• Interface humano-ordenador.
o<
"
::>
u.. • Procedim ientos algorítmicos.
La tarea de diseño también produce:
• El diseño de datos que transforma el modelo del dominio de info rmación que se
crea durante el análisis en las estructuras de datos que se necesitarán para
implementar el software.
• El diseño arquitectónico que define la relación entre los elementos estructurales

principales del software, los patrones de diseño que se pueden utilizar para lograr
los requisitos que se han definido para el sistema , y las restricciones que afectan a
la manera en que se pueden aplicar los patrones de diseño arqu itectónicos.
• El diseño de la interfaz, que describir la manera de comunica rse el software dentro

de sí mismo, con sistemas que interoperan dentro de el y con las personas que lo
utilizan.
• El diseño a nivel de componentes , que transforma los elementos estructurales de la

arquitectura del software en una descripción procedimental de los componentes del
software.

I NGENIERÍA DE SOFTWARE Y GEST IÓ N DE PROYECTOS
FUNIBER
c.- Implementación
En esta fase se desea responder la pregunta ¿cómo se construye la solución?. La

respuesta se consigue con la transformación del diseño en una aplicación ejecutable,
proceso que consiste básicamente en la traducción de las representaciones de software
a formas comprensibles po r las máquinas.
Para esto se utilizan lenguajes de programación que generan el código fuente , siendo
necesario hacer la inspección del código , como:
• uniformidad en la escritura;
• carencia de ambigüedades ;
• pureza sintáctica ;
• semántica del problema y no de la tecnología;
• compactación del código en unidades lógicas distinguibles (librerías, rutinas ,

<
z
procedimientos) ; <
u
;;:
~
• localización precisa del código que satisface un requerimiento; y , <
o
"'
w
"'
• linealidad o seguimiento de un flujo lógico y coherente . <
"'t:<
"'"'
Otras características necesarias son: ~
z
=>
z
~
• fac ilidad de traducción (diseño-código ); u
<
e
z
• eficiencia de compila ción;

.r.
• portabil idad;
• disponibilidad de herramientas y ambientes de desarrollo; y ,
• facilidad de manutención: lenguajes de programación.
d.- Prueba
La Fase de prueba pretende responder la pregunta ¿ha sido resuelto el problema? , lo

cual significa determ i nar s i la so luc i ón que ha sido con stru i da c oincide con los
requerim ientos .
Los prin cipios de una prueba son :
• A todas las pruebas se les debería poder hacer un segu imiento hasta los requisitos
del cliente.
• Las pruebas deberían planificarse mucho antes de que empiecen.

FUNIBER f~ . . . . . . . . . . . . .
I NGENIERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
~c:m . . . . . . . . . . . . . . . . . .- -
• Las pruebas deberían empezar primero ' por lo pequeño ' y luego progresar hacia 'l o
grande'.
• Deberían ser conducidas por un equipo independiente.
Los tipos de prueba son: prueba de caja blanca , prueba de caja negra, prueba de unidad
y prueba de validación.
• Pru eba de caja blanca . La prueba de caja blanc a es un método de diseño de

casos de prueba que usa la estructura de control del diseño procidemental para
obtener los casos de prueba. Mediante los métodos de prueba de caj a blanca ,
el ingeniero del software puede obtener casos de prueba que:
Garanti ce qu e se ejerciten por lo me nos una vez todo s los cam inos
independientes de cada módulo.
Se ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
Se ejecuten todos los bucles en sus límites y con sus límites operacionales.
<
z
<
~ Se base en el minucioso examen de los detalles de los procedimientos.
a:
!E<
o
~ • Prueba de la caja negra. La prueba de Caja negra se centra en los requ isitos
< funcionales del software. Pe rmite al ingeniero del software obtener conj untos
o:
<
!: de condiciones de entrada que ejerciten comp letamente todos los requ isitos
V>
~
>
funcionales de un programa. La prueba de caja negra no es una alternativa a las
z
:;:¡ técnicas de prueba de caja blanca. Más bien se trata de un enfoque
z
'°ü complementario que intenta descubrir diferentes tipos de errores que los
<
o
z métodos de caja blanca .
::>
u.
'"" Intenta encontrar errores de las sigu ientes categorías:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estru cturas de datos o en accesos a bases de datos externas .
Errores de rendimiento .
Errores de inicialización y terminación .
• Prueba de unidad . Centra el proceso de verific ación en la menor unidad del

diseño del software : el módulo. Está or ientada a caja b la nca y este paso se
puede llevar a cabo en paralelo para múltiples módu los. Las pruebas que se dan
como parte de la prueba de unidad son:
La prueba de interfaz del módulo para asegurar que la informa ción fluye de
forma adecuada hacia y desde la unidad de prog rama q u e está s iendo
probada.

FUNIBER
La prueba de est ructu ras de datos locales para asegurar que los datos que
se mant ienen t empo ralmente conse rvan su i ntegridad durante todos los
pasos de ejec ución del algoritmo .
Se prueban las condiciones de límite para asegu rar que el módulo funciona
co rr ec t am en te en los lími t es esta b lec i dos como r est r icciones de
procesamiento . Se ejercitan los caminos independientes de la estructu ra de
con trol co n el fin de asegu r ar que todas las sentencias del módulo se
ejecutan po r lo menos una vez.
Fi nalment e, se prueban todos los ca m inos de manejo de errores.
• Prueba de validación. La validación se consigue cuando el software f unciona de

acuerdo con las expectativas razonables del cliente . Se lle va n a cabo dos
pruebas:
La prueba Alfa se realiza en el lugar de desarrollo pero por un cliente. Se usa

el software de forma natural con el desarrollado r como observ ador del
usua rio y registrando los errores y problemas de uso.
<
La prueba Beta se lleva a cabo por los usuarios finales del software en sus z
<(
u
respectivos lugares de t rabajo. Como el desarrollador normalmente no está ~
>:
presente , la prueba beta es una aplicación en vivo de l software en u n <(
o
entorno que no puede ser controlado por é l. Es el cliente quien reg istra los ~
<
problemas y los informa al desarrollador. a:
<
....
¡¡;
~
• Pru eb a del sistema. Su propósito primordial es probar profundamente el ::z
sistema, ve rificando que se hallan integrado adecuadamente todos los ::>
~
elementos del sistema y que se realizan las funciones apropiadas . ü
<(
"z
::i
u.
e.- Entrega y mantenim iento
Mientras la ent rega pretende que el cliente pueda usar la solución y tenga garantías de
que es operativo , la Fase de mantenimiento busca responder la pregunta ¿se necesitan
mejoras /cambios? del tipo:
Correctivo, para reparac ión de errores;
A daptivo, para modificar el software adaptándolo a los ca mbios del ambiente

de trabajo ;
Perfectivo , p ara proveer nuevas funcionalidades de nuevos requerim ientos; y /o ,
Preventivo , para mejorar la ma nutención de l sistema y anticipar errores.
Existen los siguientes tipos de mantenimiento:
Mantenimiento correctiv o : diagnostica y co rrige errores. Representa altos

costos.

--
I NGENIER ÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
FUNIBER{'f ........................................................
Mantenim iento adaptativo : se presenta cuando es necesario un cambio de

ambient e plataforma de trabajo.
Mantenimiento perfectivo : se realiza cuando se quieren hacer mejoramientos y

adición de nuevas capacidades.
Mantenimiento preventivo : pa ra el m ejo ramient o de la mantenibilidad futura.
En el mantenimiento se presentan problemas cuando:
no se documentan los cambios;
no se comp rende el trabajo ajeno;
falt a documentación;
el diseño es inadecuado;
hay mala actitud hacia la manutención misma; y / o
<
z todas las fases del desarrollo deben considerar la manten ibilidad , con el costo
:
<
o
~
< 3.1.4.2 Modelos de desarrollo
"
~
¡;;
~
z
> La elección de la forma de desarrollo t iene un efecto sign ificativo en el éxit o del
::;,
z
-o
proyecto. El paradigma es un proceso , cuya adecuación puede conducir a una rá pida
u
<
o complet ación , costo reducido, calidad mejorada y riesgo bajo . Un proceso inadecuado o
z
::>
u.. malo conduce a esfue rzos de trabajo duplicados , pr oblemas en la programació n y
creación continua de problemas de gestión.
El proceso es una se r ie de pasos que se deben seguir para lograr ob j et ivos .

Específicamente , el proceso del software es un marco de t rabajo de las tareas que se
requieren para construir software de alta calidad.
Es necesario hacer diferencia entre " proceso" e ingeniería de software. Un proceso de

software define el enfoque a tomar cuando el software es tratado por la ingeniería. La
ingeniería de software también comprende las tecno logías que t iene el proceso -
métodos técnicos y herramientas automatizadas.
Surgidos a finales de los años 60 e inicios de los 70 , los paradigmas de desarrollo son
hoy por hoy el marco más usado de referencia para describi r el proceso de desarro ll o de
un proyecto informático o la construcción de la solución informática. También ll amados
modelos de ciclo de vida del software, desc riben los pasos a segu ir, los puntos de
t erminación , los subproductos a entregar y fases a seguir.
DIRECCION Y GESTIÓN DE PROYECTOS TIC 14 5

I NGENI ERÍA DE SO FTWARE Y GESTIÓ N DE PROYECTOS
FUNIBER ff
Lo que se persigue con estos modelos de p roceso de software es que pr oducto o
solución informática sea:
• Comprensible, c laro y bien definido en sus detalles y en el trabajo realizado.
• Bien construido, se enc uentre desarrollado con herramientas automatizadas que

permitiesen el t rabajo de 'oficina' y den espacio al t rabajo más c reativo .
• Confiable, al permitir detectar errores a tiempo o se minimice su presencia.
• Robusto, en el sentido que puede seguir operando bajo condiciones de fallo o error.
• Mantenible , o que se pueda ajustar a cambios futuros con facilidad.
• ' Barato ', es decir, construido en el tiempo adecuado y dentro de presupuestos

con venientes.
A continuación , algunos de los modelos más característicos:

<
z
<
• Modelo de Cascada. u
~
• Modelos de Procesos Incrementales: <
o"'
o:
u
"'
Modelo Incremental. <
°'<t
Modelo RAD. "'o:
u
>
z
• Modelos de Procesos Evolutivos: :::>
z
-o
u
Prototipado. <
o
z
::o
u.
Modelo Espiral.
Modelo de Desarrollo Concurrente.
• Modelos de Procesos Especializados:
Desarrollo a base de Componentes.

Modelo del Método Formal.
Desarrollo de software Orientado a Objetos.
• Proceso Unificado .
Luego , se destaca el e-Project como un caso especial de alta rele vancia a e-Business.
a.- Modelo en cascada
Es el más básico de todos los modelos de ciclo de v ida y de hecho sirve de base para
otros modelos. Fue originalmente documentado por Royce en el año 1970, lo que lo
convierte en el paradigma de ingeniería de software más antiguo. El modelo de cas cada
ve el desarrollo como una secuencia simple de fases ( ) que empieza con la

IN GENIERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
especificación de requerimientos y prosigue con la planificación, modelamiento ,

construcción y desarrollo, culminando en el soporte del software completo.
En cada fase se debe realizar un proceso de veri fic ación y validación (V&V, Validación :
¿estamos construyendo co rr ectamente el producto?; Verificación: ¿estamos
construyendo el producto correcto?).
Este modelo de trabajo se basa en los siguientes principios básicos:
• Plan de Proyecto antes de embarcarse en él.
• Definición del comportamiento externo del sistema deseado .
• Documentación de los resultados de cada actividad.
• Diseño del sistema previo a la codificación.
• Prueba del sistema antes de su construcción.
Comunicadón
- .. P~neaclón
ca1a11o Modelado
Programao0n Construcdón
Se<}um-.0 AAi!ISIS
Diseño
Figura 3.3: Modelo en cascada.
El modelo original incluía además bucles de retroali ment ación; sin embargo, la mayoría
de las o rganizaciones que ap lican este modelo de procesos lo utilizan secuencialmente y
de form a lineal.
Este modelo funci ona cuando lo s requerimientos del problema son razonables y bien
comprendidos , y el riesgo de inestabilida d es bajo. En los últimos ti empos se ha
cuest ionado la eficiencia del modelo en casca da . Algunas de la s razones son la s
siguientes :
• Los proyectos rea les raramente siguen un orden secuencial.
• Usualmente es difícil lograr que el cliente otorgue requerimientos explícitos a alto

nivel.
• El cliente debe se r paciente y esperar a ve r resul t ados al final del proceso. Se

'
produce un caos cuand o un error grave es detectado en una etapa muy avanzada
del proyecto de software.

b.- Modelos incrementa les
En situaciones en las que los requerimientos iniciales están bien definidos, pero que
según el alcance del proyecto existe la posibilidad de que el desarrollo no sea linear, se
provee de un modelo de procesos que está diseñado para producir so f tware por
incrementos. Para ello, limitan la funcionalidad del software para que pueda se r revisado
por el c li en t e y que éste a su vez lo refine para tene rlo listo en la siguiente fa se del
proyecto.
b . 1- Modelo increme ntal
El modelo incremental combina los elementos de l modelo de cascada , ap li cándolo de

forma iterat iva . Aplic a secuen cias lineares a modo de fases, co m o progresos de t iempo
calenda rio. Cada secuencia linear produce "increm entos" entregables del software.
El modelo de procesos incremental es ite r ativo po r naturaleza. Sin embargo, este

modelo se enfoca en la entrega de un producto operacional con cada incremento. <
z
<
~
~
El desarrollo incremental es pa rticu larmente útil cuando el personal no está disponible >:
<
o
para hace r una implementación comp leta para la fecha aco rd ada con el cliente. Los ~
"<
incrementos de etapa t emprana pueden ser eje cutados por una meno r cantidad de
"'<
personas. ¡¡¡
5>
z
::;¡
z
·O
ü
<
o
z
Comun1cac1ón "
u..
:2
Planificación
Modelado (anáhs1s, diseño)

8. Incremento 11 n
"'~ Construwon ( cod1go, prueba)
>
c.i
:;; Despliegue (enoega, reacción)
!
b
"'
C)
Incremento t: 2 • Entrega de
incremento enésuno
"""Q
ti)
ti)
e Entrega de
8
e
Inaemento :: 1 2 incremento
::>
L....
Entrega de
1 incremento
Tiempo de calendano de Proyecto
Figura 3 .4: Modelo incremental.
148 DI RECCION Y GESTIÓN DE PROYECTOS TIC

FU N I BE R f ~ 1::::;;;;;;;;;;;;;;;;;;:;;;;;;;:;¡¡;¡¡¡¡:;;¡..:;¡;:z:=====1 N::G:1E¡;¡N:;::1E
:;z;R::í=A=o=E=s=o=F=T=w::A:aRz:E::;v:ilG.:Eas:z::To:z1ó::..N:;¡¡¡:o¡s;E:;;;P;;:R::o;::vizEc::o:T;.;:oz:;:is
b.2. - Modelo RAD
Es un modelo de proceso en cascada que enfatiza un ciclo de desarrollo

extremadamente corto.
Entre 60 y 90 días
Modelado
de gest>ón
Modelado
de datos
Modelado
de proceso
Generación
de aphc.aciones
<
z
<
~
o: Pruebas y
>: entrega
<
...~
"'
:oo:
<
.... Figura 3.5: Modelo RAD.
¡¡;
o:
>
z
::>
z El Modelo RAD es una adaptación a alta velocidad del mode lo lineal secuencial en
·O
u
<
e
cascada, en el que se enfatiza un cic lo de vida extremadamente corto ( ),
z
::>
u.. utilizando un enfoque de const rucción basado en componentes o de módulos
reutilizables , y haciendo especial hincapié en el uso de entornos 4G L 2 e IPSE 3 ,
bibliotecas de componentes o módulos, orientación al objeto , etc .
Si se comprenden bien los requisitos y se limita el ámbito del proyecto , el proceso RAD
permite al equipo de desarrollo crear un sistema complet amente func io nal dentro de
períodos cortos de tiempo , como por ejemplo en un período de 60 a 90 días.
No es adecuado en entornos tecnológicos nuevos o en entornos que requ ieran

interoperatividad con aplicaciones existentes pues , por ejemplo , no se dejará el tiempo
suficiente para pruebas de integración.
2. 4GL, Fourth generation /anguage Lenguaje de alto nivel, usualmente no procedura l, que perm ite a usuarios sin mucha
experiencia programar aplicaciones de bases de datos. Por ejemplo, el lenguaje SQL (Structured Query Language).
3. IPSE, lntegrated Project Support Environment Térm ino usado para designar un conjunto de herramientas técnicas y de
gestión destinadas a dar soporte al desarrollo de un software, usualmente dentro de marco integrado y coherente de
trabajo.

I NG EN IERÍA DE SOFTWARE Y GEST IÓN DE PROYECTO S
FUNIBERff
Cu ando se lo ut iliza prin cipa lment e para aplicaciones de sistemas de info r mació n este
enfoque comprende las siguientes fases.
• Modelado de Gestió n. El flujo de información entre las funciones de gestión se

modela de forma que responda a las siguientes pregunt as:
- ¿Qué info rm ación condu ce el proceso de gest ión?
- ¿Qué información se genera?
- ¿Quién la genera?
- ¿A dónde va la información?
- ¿Qui én la procesa?
• Modelado de Datos . El flujo de info rmación definido como parte de la fase de

modelado de gestión se refina como un conjunto de objetos de datos necesa r ios
para apoyar la empresa. Se definen las características de cada uno de los objetos y
<
las re laciones entre estos objetos . z
<
u
~
• Modelado de Pro ceso . Los objetos de datos definidos en la fase de modelado de "<oo:
w
datos queda n transformados para lograr el fluj o de información necesario para "'
~
implementar una función de gestión. Las descripciones del proceso se crean pa ra o:
<
~
;¡;
añadir, modificar, suprimir , o recuperar un objeto de datos. o:
u
>
z
::J
• Generación de A plicaciones . El RAD asume la utilización de técnicas de cuart a z
o
u
generación. En lugar de crear el software con lenguajes de programación de terce ra <
o
z
generación por ejemplo, un len guaje de programación), el proceso RA D trabaja para ::>
u..
volver a utilizar componentes de prog ramas ya existentes cuando esto es posib le, o
se crean componentes reutilizables cuando es necesario . En todos los casos se
utilizan herramientas automáticas para facilitar la const rucción del software.
• Pruebas y entrega . Como el proceso RAD enfatiza la reutilización, ya se han

comprobado muchos de los componentes de los programas. Esto reduce el tiempo
de pruebas. Sin embargo , se deben p robar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.

I NGENI ERÍA DE SOFTWARE Y GESTIÓ N DE PROYECT OS
c.- Modelos evolutivos
Se sabe de antemano que el software al igual que todos los sistemas complejos ,
evoluciona con el tiempo. En el modelo lineal secuencial se asume que el sistema va a
entregarse completo una vez que la secuencia lineal se haya finalizado, así mismo en el
modelo de construcción de prototipos se diseña con la especifica idea de ayudar al
cliente a comprender los requ isitos , en ninguno de estos modelos se toma en cuenta la
natu raleza evolutiva del software.
Los modelos e v olutivos se caracterizan por desarrollar versiones cada vez mas
completas del software.
c . 1 .- Modelo en espiral
El Modelo en espiral surge como medio para enfrentar grandes sistemas compuestos de
muchos subsistemas, en cuyo caso se puede seguir un prototipado para
<
z
especificaciones de alto riesgo y un modelo en cascada para desarrollos claros.
:
<
o
Pro porciona el rápido desarrollo de versiones increméntales de software , estas
.,::: versiones se pueden considerar como un prototipo. En este modelo el radio representa
~
"'< el costo, una distinción importante es que el producto estará terminado al finalizar el
!::
:::"'> espiral , no al terminar cada ciclo.
z
::>
z
-o El Modelo en espiral fue propuesto por Bohem como un modelo híbrido caracterizado
;:¡
<
o
z
por:
::>
u.
• combinar la naturaleza iterativa de construcción de prototipos con los aspectos

controlados y sistemáticos del modelo en cascada ;
• no se fijan fases, la s fases las decide el gestor del proyect o;
• el producto surge en una serie de versiones incrementales;
• el modelo se divide en tareas ; y,
• pueden existir áreas o regiones de tareas (entre 3 y 6) .
DI RECCIÓN Y GESTI Ó N DE PRO YECTOS TIC 151

FUNIBER
Planeación
Cálculo
Comunicación Programación
Segu1m1ento
Iniciación del proyecto
Reunión de requisitos Modelado
Análisis
Diseño
-....., -~ Inicio
Entrega
Apoyo Construcción
Retroalimentación Código
Prueba
Figura 3.6: Modelo en espiral.
..
<
z
u
§
:¡:
<
:;;..,
Evaluaoon altemaovas "'
1dent1ftca, resuelve riesgos ::
«
<
>-
Determina obJE!tM>S AnailSIS "'«
~
a!temativos y ?:
nesgos
restnct1vos 3
AnahSIS z
-o
nesgos ¡:;
<
e
z
Aniihs1s
nesgos
"
u..
Prototipo
Prototipo
operacional
Protoopo 3
Anahs1s
2
nesgas
Protonpo
REVISION
1
Plan requenm1entos S1mulaoo...es, modelos, benchmarks
Plan ocio de Vida Concepto de la
operación
Requerimientos
de S/W Diseño
producto Diseño
detallado
Plan de Vahdaoón
desarrollo requerimiento
Codificación
Integración r Diseño Test unidad

plan test V&V Test
Test 1ntegrac1ón
servicio aceptaoón
Figura 3 .6b: Modelo en espiral.
152 DIRECCIÓ N Y GESTIÓ N DE PROYECTOS TI C

T ales áreas son:
• Comunicación con el cliente.
• Planificación y re-pla nificación pa ra (re) definir recursos , ti empos, et c.
• Análisis de riesgos técnicos y de gestión.
• Ingeniería para constru ir representaciones de la aplicación , software o so lución

informát ica.
• Construcción y adaptación , prue ba y soporte al usuario.
• Evaluación y análisis de reacción del cliente .
Según la figura ant erio r, se progresa del cen t ro d e la espira l en el sent ido de las agujas
del reloj, especificando prog resivament e subp roductos y /o v ersiones mejoradas y más
sofisticadas del producto f inal , co nstruyendo protot ipos para gara nt izar el t rabajo
futuro.
<
z
<
u
El modelo se basa en los principios de:
~
"'
<
o • flexibilidad ;
~
< • eliminación temprana de erro res ;
"'
<
....
"'"'w • integ ración de desarrollo y mantenimiento; y ,
~
z
"'oz • reu t ilización .
ü
<
o
z
:>
c.2 .- Modelo de construcción de prototipos
u.
g
Escuchar al cliente Construir / revisar prototipo
Plan de Avance Rápido

(Quick Plan)
Comunicación
Modelamiento Diseño Rápido

(Quick Design)
Despliegue, entrega
y retroalimentación Construcción
de prot otipo
Cliente prueba prototipo
Figura 3.7: Modelo de construcción de prototipos.

FUNIBER~f
lNGEN I ERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
Un paradigma de construcción de prototipos puede ofrecer un mejor enfoque cuando:
• Un cliente define un conjunto de objetivos generales para el software, pero no

identifica los requisitos detallados de entrada , procesamiento o salida.
• El responsable de desarrollo del software puede no estar seguro de la eficacia de un

algoritmo, de la capacidad de adaptación de un sistema operativo , o de la forma en
que debería tomarse la interacción hombre-máquina.
• El desarrollador y el cliente encuentran y definen los objetivos globales para el

software, identifican los requisitos conocidos , y las áreas del esquema en donde es
obligatoria más definición.
• Se realiza un diseño rápido. Este diseño se centra en una representación de esos

aspectos del software que serán visibles para el usuario/ cliente como por ejemplo
los enfoques de entrada y formatos de sal ida.
• Luego el diseño rápido lleva a la construcción de un prototipo el cual es evaluado

por el cliente/ usuario y utilizado para refinar los requisitos del software a desarrollo. <
z
<
~
• Finalmente , la interacción ocurre cuando el prototipo satisface las necesidades del ~
:E
cliente, a la vez que permite que el desarrollador comprenda mejor lo que se <
o
ffi
necesita hacer . "'
~
o:
<
• En la mayoría de los casos, el primer sistema por lo general es demasiado lento, 1-
¡¡;
5
grande o torpe en su uso por lo cual la mayoría opta por desecharlo y comenzar el ::
z
::>
desarrollo de uno nuevo , corrigiendo las deficiencias encontradas en el primer o
z
u
prototipo, que su rgieron durante las evaluaciones con el cliente / usuario. <
o
z
:>
"-
d.- Métodos ágiles
En años recientes , diversas ideas han sido publicadas en cuanto a formas de hacer el
proceso de desarrollo de software más ligero o ágil de implementar y con mejor
respuesta a las necesidades de los clientes.
Estos métodos (que incluyen o también se denominan metodologías) han demostrado

sus beneficios en términos de time-to-market (respuesta a las necesidades y velocidad
del mercado), adaptabilidad a la evolución de los requisitos, satisfacción del cliente, y
entrega de productos rápidame nte y dentro del presupuesto estipulado en un cierto
número de dominios.
A continuación el método Ágil más popular y ampliamente empleado a nivel industrial:

la programación extrema o eXtremme Programming (X P) . A conti nuación se procede
con una re visió n más breve de otros métodos.
154 DIR ECCIÓ N Y GESTJON DE PROYECTOS TIC

I NG EN IERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
d.1. eXtreme Programming
La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería

de software formulado por Kent Beck en 1 999 4 . Es el más destacado de los procesos
ág iles de desarrollo de sof tware. A l igual que éstos, l a programación ext r ema se
diferencia de las metodologías tradicionales principalmente en que pone más énfasis en
la adaptabilidad que en la previsibilidad. La capacidad de adaptación a los cambios de
requisitos en cualquier punt o de la vida del proyecto , experimental mente demuestra ser
una aproximación mejor y más realista que intentar definir todos los requ isitos al
comienzo del proyecto e inve rtir esfuerzos después en controlar los cambios en los
requisitos.
Los principios originales de la programación extrema son:
Simplicidad
Comunicación
Retroalimentación (feedback) y
Co raje .
<
;;¡
< Durant e la revisión del libro un quinto principio fue añadido: Respeto .
t::
"'::;
>
z
::>
Los cinco pr incipios se detallan a continuación:
z
·O
ü
<
o
z
::>
u..
La simplicidad es la base de la programación extrema. Se simplifica el diseño

para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del
código junto a sucesivas modificaciones por parte de diferentes desarrolladores
hacen que la complejidad aumente exponencialmente. Para mantener la
simplicidad es necesaria la refactorización del código, ésta es la manera de
mantener el código simple a medida que crece. También se aplica la simplicidad
en la documentación, de esta manera el código debe comentarse en su justa
Simplicidad
medida, intentando eso sí que el código esté autodocumentado. Para ello se
deben elegir adecuadamente los nombres de las variables, métodos y clases.
Los nombres largos no decrementan la eficiencia del código ni el tiempo de
desarrollo gracias a las herramientas de autocompletado y refactorización que
existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del
código y la programación por parejas se asegura que mientras más grande se
haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.
4. Beck K. (1999 ) Extreme Programming Explained Embrace Change. ISBN 0201616416 Edit: AddisonWesley

FUNIBERf~
La comunicación se realiza de diferentes formas. Para los programadores el

código comunica mejor mientras más simple sea. Si el código es complejo hay
que esforzarse para hacerlo inteligible. El código autodocumentado es más
fiable que los comentarios ya que éstos últimos pronto quedan desfasados con
el código a medida es modificado. Debe comentarse solo aquello que no va a
variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las
Comunicación
pruebas unitarias son otra forma de comunicación ya que describen el diseño de
las clases y los métodos al mostrar ejemplos concretos de cómo utilizar su
funcionalidad. Los programadores se comunican constantemente gracias a la
programación por parejas. La comunicación con el cliente es fluida ya que el
cliente forma parte del equipo de desarrollo. El cliente decide que características
tienen prioridad y siempre debe estar disponible para solucionar dudas.
Al estar el cliente integrado en el proyecto, su opinión sobre el estado del

proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales
se muestran resultados, se minimiza el tener que rehacer partes que no
cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es
más importante. Considérense los problemas que derivan de tener ciclos muy
Retroalimentación largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los
criterios del cliente o malentendidos por parte del equipo de desarrollo. El <
código también es una fuente de retroalimentación gracias a las herramientas ~
u
de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de ~
>:
salud del código. Ejecutar las pruebas unitarias frecuentemente permite <
o
descubrir fallos debidos a cambios recientes en el código. "'
w
"'
<
;;;
Los puntos anteriores parecen tener sentido común, entonces, ¿por qué coraje?. ....<
Para los gerentes la programación en parejas puede ser difícil de aceptar, parece "'~
como si la productividad se fuese a reducir a la mitad ya que solo la mitad de los ::
z
::>
programadores está escribiendo código. Hay que ser valiente para confiar en z
<>
que la programación por parejas beneficia la calidad del código sin repercutir u
<
negativamente en la productividad. La simplicidad es uno de los principios más o
z
,;:_
difíciles de adoptar. Se requiere coraje para implementar las características que
Coraj e
el cliente quiere ahora sin caer en la tentación de optar por un enfoque más
flexible que permita futuras modificaciones. No se debe emprender el desarrollo
de grandes marcos de trabajo (frameworks) mientras el cliente espera. En ese
tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de
desarrollo no recibe retroalimentación para saber si va en la dirección correcta.
La forma de construir marcos de trabajo es mediante la refactorización del
código en sucesivas aproximaciones.
El respeto se manifiesta de varias formas. Los miembros del equipo se respetan

los unos a otros, porque los programadores no pueden realizar cambios que
hacen que las pruebas existentes fallen ó que demore el trabajo de sus
Respeto
compañeros. Los miembros se respetan su trabajo porque siempre están
luchando por la alta calidad en el producto y buscando el diseño más óptimo
para la solución a través de la refactorización del código.
Tabla 3.1. Principios de la programación extrema.
El éxito de la programación extrema radica en que enfatiza la implicación del cliente final
y el trabajo en equipo. Es el resultado de la adopción de las mejores metodologías de
desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de
1 56 DIRECCIÓ N Y GESTIÓ N DE PROYECTOS T IC

manera dinámica durante el ciclo de vida del software. Para ello, se basa en reglas
simples y en la práctica, que se apoyan de forma mutua.
El Mapa XP muestra la mane ra conjunta de trabajo para formar una metodología de

desarrollo.
Todo el
Prácticas XP equipo
Propiedad Cod1ficac1ón
colectiva Estándar
Desarrollo
bajo prueba
Prueba de Programación Desarrollo

cliente en parejas Refactonzac1ón planificado
Diseño
Integración símple Trazo
continúa sostenible /
"'"'
>
z Metáfora
/
:::;¡
z
-O
ü
<
e
z
"'
u.
Desarrollo
incremental
Figura 3.8: Mapa de Programación Extrema.
Las características fundamentales del método son:
• Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
• Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo

pruebas de regresión.
• Programación 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
código escrito de esta manera -e l código es revisado y discutido mientras se
escribe- es más importante que la posible pérdida de productividad inmediata .
• Frecuente integración del equipo de programación con el cliente o usuario. Se

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

FUNIBER
• Correción de todos los errores antes de añadir nueva funcionalidad. Hacer entregas
frecuentes.
• Refacto rización del código, es decir, rec reaba is ciertas partes del código para
aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las
pruebas han de garantizar que en la refact orización no se ha introducido ningún
fallo .
• Propiedad del código compartida: en vez de dividir la responsabilidad en el

desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el
que todo el personal pueda corregir y extender cualqu ier parte del proyecto. Las
frecuentes pruebas de r eg r esión garantizan que l os posibles errores serán
detectados.
• Simplicidad en el código: es la mejo r manera de que las cosas funcionen. Cuando

todo funcione se podrá añadir func ionalidad si es necesario. La programación
extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo
extra pa r a cambiarlo si se requiere, que realizar algo complicado y quizás nunca
utilizarlo.
La simplicidad y la comunicación son extrao rdi n ariamente complementarias. Con más

comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras
más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una "'"'
>
z
comunicación más completa , especialme n te si se puede reducir e l equipo de :;¡
z
o
programado res . ü
"'oz
:::>
u..
d.2. Otros métodos
A continuación se ent rega un boceto de otros métodos ágiles 5 .
• Adaptíve Software Oevelopment (ASO). Es una metodología de adaptación

continua o que se adapta al cambio en lugar de luchar contra él , en base a
circunstancias cambiantes . En ella no hay un ciclo de planificación-diseño -
s. Para esta sección se han consultado y considerado texto de las siguientes fuentes:
• Adaptive. Enlace web: http: .. ,., .. adaptkPsd.com
• AMARO CALDERÓN, SARAH DÁMARIS; VALVERDE REBAZA, JORGE CARLOS. (2007). Metodologías Ágiles. Universidad
Nacional de Trujillo. P. 37. Perú.
• IBM. RUP. Enlace web: http:, ww-01 jbm.co'Tl'sof¡ware awdtools, -up'
• OLGUÍN, JOSÉ. (2009). El Proceso Unificado de Desarrollo de Software (RUP).
Enlace web: r· ; ac . - ,,2:;.c .,...} ~.,-,~ ~ _,,., :i<- PL ~ "'tm
• Poppendieck.llc. Lean Software Development. Enlace web: htto·, fl', •• ,. Q?ooend·ecr.. corl'
• REYNOSO, CARLOS. (2004 ). Métodos Heterodoxos en Desarrollo de Software. Universidad de Buenos Aires. P. 80.
• RUSK, JON. (2006). Crystal Clear Methodology. En Agilewiki.
Enlace web: htrn &.,v.. ag. e< com1other amle mst2 1-clear-r1ethodR1ocv 1
• SCRUM. Enlace web : htt;J: . · w <.crum.org
• SCRUMAlliance. Enlace web: - 0 · wwv.. scrvo12l11ance.o·nf
158 DIRECCIÓN Y GESTIÓN DE PRO YECTOS TIC

INGENIERÍA DE SOFTWARE Y GESTIÓN DE PROYECTO S
const r ucción del software, re em plaza al paradigma de cascada por un ciclo

especular-colaborar- ap r en d er . Sus p r i nci pales ca r acterísticas son: iterat i vo,
orientado a los componentes softwa re más que a las tareas y, to lerante a los
cambios. A g randes rasgos, ASO p resupone que las necesidades del c liente son
siemp re cambiantes. La iniciación de un proyecto involucra defini r una misión para
él, determinar las ca racterísticas y las fechas y descomponer el proyecto en una
ser ie de pasos ind ividuales, cada uno de los cuales puede abarcar entre cuatro y
ocho semanas. Los pasos iniciales deben verificar el alcance del proyecto; los
tardíos tienen que ver con el diseño de una arquitectura , la construcción del código,
la ejecución de las pruebas finales y el despliegue.
• Lean software development . El término proviene de Lean Manufac turing , que

define un enfoque de producción basado en la reducción de desperdicios, y que se
ha traducido en un conjunto de principios y prácticas or ientados a una estrateg ia de
gestión y aplicados al desa rrollo de software. Los principios son: eli minar desechos,
ampliar el aprendizaje, decidir tan ta rde como sea posible, entregar/reaccionar ta n
pronto como sea posible , potenciar (empower) al equipo, crear una percepción de
integridad del producto , y ver el todo /el conjunto . Ejemplos de prácticas son: tener
a la vista los desperdicios, mapear la cadena (stream) de valor (conocer el origen y
destino de las acciones de valor), desarro l l ar en base a conjuntos de
requerimientos, producir en base a un sistema pul/ (tiraj e, cercano a la producción
justo a tiempo -just in time-) , aplicar un enfoque de t rabajo de cola de tareas,
motivar, y medir.
• Crystal Clear. Es un tipo de metodología (agrupada dentro de las metodologías

Crysta/ por algunos autores) que presenta un enfoque ágil de trabajo , con gran
énfasis en la comunicación, y con cierta toleranc ia , lo que la hace ideal en los
casos en que sea inaplicable l a disciplina r equerida por XP (eXtremme
Programming). Crystal Clear es la versión más conocida y supuestamente ág il de
las metodologías Crystal. Da énfasis a la comunicac ión y es liv iana en relación a los
entregables . Crystal maneja iteraciones cortas con feedback frecuente po r parte de
los usuarios / clientes, minimizando de esta forma la necesidad de productos
intermedios, y requiere disponer de un usuario real aunque sea de forma part time
para realizar va lidaciones sobre la Interfase del Usuario y para participar en la
definición de los requerimientos funcionales y no funcionales de l softwa re.
• Scrum. Define un proceso empírico , iterativo e incremental de desarrollo que

intenta obtener ventajas respecto a los procesos o paradigmas clásicos (cascada ,
espiral, prototipos , etc.) mediante la aceptació n de la naturaleza caótica del
desar rollo de software , y la utilización de práct ic as tendientes a manejar la
impredictibilidad y el riesgo a nive l es aceptables. Nació para productos
tecnológicos. Sin profundizar, se puede decir que Scrum es un método iterati vo e
incremental que enfatiza prácticas y valo res de project management por sobre las

FUNIBER~
I NGENIE RÍA DE SOFTWARE Y GE STI ÓN DE PROYECTOS
demás disciplinas del desarrollo. Al principio del proyecto se define el Product

Backlog , que contiene todos los requerimientos funciona les y no funcionales que
deberá satisfacer el sistema a construi r . Los mismos estarán especificados de
acuerdo a las convenciones de la organización ya sea mediante: features, casos de
uso, diagramas de flujo de datos, incidentes, tareas , etc. El Product Backlog será
definido durante reuniones de planeamiento con los stakeho/ders. A partir de ahí se
definirán las iteraciones, conocidas como Sprint en la juerga de Scrum, en las que
se irá evolucionando la aplicación evolutivamente . Cada Sprint tendrá su prop io
Sprint Backlog que será un subconjunto del Product Backlog con los requerim ientos
a ser construidos en el Sprint correspondiente. La duración recomendada del Sprint
es de un mes.
• RUP. Rational Unified Process (RUP). No es un método o m etodolog ía ágil pero

conviene añadirla por su relevancia. Es un proceso de desarrollo de software que
define pasos en espiral. Los principios que los rigen son adaptar el proceso ,
equilibrar prioridades, demostrar valor en cada iteración e iterativamente ,
colaboración entre equipos, elevar el nivel de abstracción aprov echando patrones, y <
z
<
u
enfocarse en la calidad. Provee un enfoque disciplinado en la asignac ión de tareas y "'~
responsab ilidades dentro de una organización de desarrollo. Su meta es asegurar <
o
~
una producción de software de muy alta calidad que satisfaga las necesidades de
:;:
los usuarios finales , dentro de un calendario y presupuesto predecible. "'<
~
¡¡;
"'
~
:!
z
=>
3 .1.4.3 Modelo e-Project z
-~
u
<
":::>z
LL
Este tipo de proyectos requiere especial atención dada su relevancia en un proyecto e-
Business. Por definición, un e-Project es un proyecto de natura leza informát ica que
involucra crear o cambia r código fuente desplegado sobre Internet . Esto incluye trabajar
con contenidos en HTML o applets en Java y ActiveX. Los proyectos que entran en esta
catego ría marcan un efecto significativo en la manera en que las emp resas manej an sus
negocios.
De pasados estudios, organizaciones como McKinsey & lnc. , mostraron que aquellos
proyectos completados a tiempo y con presupuesto excedido de un 50 % , han resultado
ser un 25 % más rentables que proyectos completados dentro de los presupuestos pero
6 meses más tarde. Cuando el proyecto , se trabajo un enfoque e-Business, estos
resu ltados se amplifican moviéndose a la velocidad del tiempo Internet ('Internet time') .
Esta comprensión del tiempo , marcada además por presiones de mercado , es un reto
pa ra los directores de proyecto.
1 60 DIRECCIÓN Y GESTIÓ N DE P RO YECTO S T I C

I NGENIER ÍA DE SOFTWARE Y GESTIÓN DE PROY ECTOS
Un e-Project se distingue de otros proyectos por:
• La frecuencia de liberación de un resultado es menor , típicamente d ías o pocos

meses.
• El alcance del producto entregado es más pequeño , por ejemplo , cambiar una sola
aplicación o corregir un bug.
• El proceso seguido es iterativo.
La muestra otras diferencias.
'' ·'·Kk': ~· ;'1·"'' ··¡~. ·' ~4•n"·'""'' ' º"' ~~ ·

- -
u•:..jqo:l1•a•1·.(:.{'!.i[t]íür. ,., • 11r.
Proyecto tradicional
·' --
Jü'l!Ii}f="'-='-'•'ltr•Ja1 ..
........... ·' ~
e-Project.
·\:
Recogida de requerimientos Riguroso Limitado

Especificaciones técnicas Robusto Descript ivo
<
z
< Duración del proyecto Años Días, semanas o meses
~
~ Prueba y cal idad Esfuerzo por conseguir objetivos Enfoque en control del riesgo
;¡;:
<
o
~ Gestión del riesgo Explícito I nherente
"'
< Vida media del producto entregado 18 meses o más 3 a 6 meses o menos
...°'< Riguroso Expedito
Proceso de entrega
"'
~
z Obtenido automáticamente de la
::> Servicio post-entrega Requ iere un esfuerzo proactivo
z interacción con el usuario
o
u
<
o
z
::>
u. Tabla 3.1. Diferencias entre un proyecto tradicional y un e-Project.
Existen tres tipos de e-Project:
• Nuev a construcc ión.
• Remodelamiento .
• Manutención .
Estos proyectos se distinguen entre sí, tanto por su duració n y la naturaleza de lo q ue

se hace en ellos , como por las actividades a realizar. Sobre est o últi m o se debe desta car
que por ser proyectos más rápidos y a trabajar sobre problemas , situaciones o
productos más pequeños , requieren menos tareas a cu mpl ir, no obstante se c lama que
es mejor no seguir proceso alguno.
DIR ECCIÓN Y GESTIÓN DE PROYECTOS TI C 161

FUNIBERf~
I NGEN I ERÍA DE SO FTWAR E Y GEST IÓ N DE PROYECT OS
a.- Project de nueva construcción
En este tipo de pro y ectos de tamaño medio podrían incluirse como ejemplos la
construcción de una casa o un análisis costo / beneficio , entre otros. En este tipo de
proyectos toma pocos meses completar la imp lementación inicial. Po r ejemplo, un e-
Shop o un B2 B.
Respecto del proceso a seguir es conveniente una implantación acelerada , por este
motivo, en caso de seguir fases , pasos o etapas, estos deben ser pocos y efect ivos. La
Muestra las etapas de e-Project: descubrimiento, diseño, desarrollo y
despliegue.
• La fase de descubrim iento se enfoca al anál isis del negocio del proyecto. Por
ejem plo , un an álisis de reque rimie ntos, un análisis de n egocio o una re-ing eniería .
• La fase de diseño es usada para crear el documento de requerimientos,

especificaciones técn icas y criterios de aceptación.
• La fase de desarrollo es para la prog ramación, diseño gráfico, implantación técnica

<
y criterios de ca lidad. z
<
~
e;
• La fase de despliegue incl u ye actividades de marketing y otras actividades de post- "<o
entrega como servicio al cliente y operaciones. ~
!:
"'~
¡;;
~
>
Descubrimiento • z
::J
z
•O
¡:;
<
o
Diseño z
::>
u.
Desarrollo
Despliegue
Figura 3.9 : e-Projectde nueva construcción.
b. - Projectde remodelamiento
Son proyectos de cambio , sea añadir , quitar y/ o modificar . Se caracterizan porque los
cambios se real izan , mientras se mantiene el serv icio on-line. Estos proyectos pueden
durar semanas.
El proceso a seguir en el rem odelamiento debe ser acelerado y , por consigu iente , inc luir
pocas fases . Usualmente el desc ubrimiento y el despliegue son asociadas al proyecto
como un todo, a excepción de nuevos requerimiento s, salv o que tenga un impacto
mayor que requiera una nuev a constr ucción .
162 DIRE CCI ÓN Y GESTIÓN DE PROY ECTOS TIC

FUNIBERfj ..................................................
La muestra el proceso a seguir, el cual involucra principa lmente diseño y

desarrollo.
Descubrimiento
Diseño
Desarrollo -
Despliegue
Figura 3. 10: e-Project de remodelamiento.
• La fase de diseño se dedica a cambiar documentac ión para introducir, el im inar y/ o

<
z
:
"oa: • La fase de desarrollo se dedica a generar nuevos programas y probarlos , cambiar
w
"< diseños gráficos, implantación técnica y , consecución de crite rios de calidad

a:
";;; existentes y creación de nuevos c riterios.
~
>
z
::>
z
c.- Projectde manutención
·O
u
<
o
z Son proyectos de mantenimiento similares a cualquier otro, no obstante, se dist in guen
::>
u..
porque son en tiempo real. Aquí se incluyen trabajos para eliminar bugs fijos o hacer
mejoras menores a un software, cambios de contenido u otras tareas cotidianas . Estos
proyectos duran pocos días.
El proceso de manutención no sigue un pat rón fo rm al de ejecuc1on como en los casos

anteriores , más bien debe contar con procesos de liberación de productos que sean
breves , rápidos y eficientes, pero lo suficientemente rigurosos que posibiliten una rápida
gestión de la configuración 6 .
Esta liberación de productos , que principalmente son correcciones , puede consegu irse
con páginas o templates de mantenimiento en los cuales los ítems descriptivos de un
mantenimiento queden registrados en bases de datos para efectuar su seguimiento.
Tales ítems pueden ser:
6. Gestión de la configuración. Por definición la gestión involucra identificar y definir las partes del sistema, controlar los
cambios a los largo del ciclo de vida, reg istrar e informar el estado de las partes y los requisitos de cambio, y verificar
la completitud y correctitud de las partes o componentes. En términos de control de la configuración, después de
establecer la configuración del sistema informático, es el proceso de evaluar y aprobar cambios a la configu ración y a
las interrelaciones entre los componentes del sistema.

FUNIBERf~
I NGENIERÍA DE SO FTWARE Y GESTIÓ N DE PROY ECTOS
• fecha de la liberación,
• nombre del solicitante ,
• nombre de los involucrados en el mantenimiento ,
• número de versión,
• descripción de la ta rea realizada ,

• detalle de la tarea realizada ,
• páginas de mantenimiento previas afectadas ,

• esfuerzo estimado ,
• esfuerzo real ,
• urgencia,
• fecha de inicio ,
• fecha de término ,
<
z
• fecha de actualización (up/oad) , 
o:
<
~
¡;;
::;
::.
3.1.5 SEGÚN DIMENSIÓN ORGANIZACIONAL z
::>
z
o
ü
<
o
z
Esta dimensión permite distinguir un proyecto según las diferentes formas ::>
u.
organizacionales que se ven involucradas en un proyecto. La dimensión organizacional º

se define administrativamente por su estructura organizacional y por su equipo de
trabajo.
a.- Estructura organizacional
Existen diferentes formas de estructura organizac ional: funcional , por proyectos ,

matri cial, o mixta.
Estas estructuras se pueden consultar más adelante en este documento.
En esta dimensión se distingue el proyecto por su estructura organizacional (ver formas

de estructuras más adelante).

FUNIBER f1 ..............................................
b.- Equipo de trabajo
Los equipos en un proyecto son organizados de muchas maneras , cada una de las
cuales tiene un efecto en la eficiencia de su desempeño . Una estructura de proyecto
inadecuado puede conduci r a tiempos de desarrollo extensos, costos altos , calidad
pobre, mala comunicación y mora l baja, además de una alta rotación , todo lo cual
puede conducir a la cancelación o térm ino de l proyecto.
No existen estructuras apropiadas a todos los proyectos informáticos, una estructura de

equipo responde a un orden y una organización única para un determinado tipo de
proyecto y para un determinado producto o servicio a generar. Su re-usabilidad en otro
proyecto podría ser desastrosa .
A continuación se muestran cuatro tipos habituales de estructuras de equ ipos para

proyectos:
<
z
• lsomórfico.
<
u
~ • Especialistas .
:t
<
o
..
~
• Democrático .
• Programador líder.
b . 1 .- Equipo de proyecto isomórfico
Un equipo isomórfico se organiza según la estructura de los principales módulos de

software ( ) . Cada miembro del equipo es asignado a un módulo de software
específico de inicio a fin. Las ventajas de esta estructura son:
es organizacionalmente simple ;
muchas tareas son desarrolladas de forma paralela; y
las tareas pueden ser claramente definidas y comprendidas.
DIRECCI ÓN Y GESTIÓ N DE PROYECTOS T IC 165

l NGENIERfA DE SOFTWARE Y GESTIÓN DE PROYECTOS
FUNIBER
Director
de proyecto
MÓdulo A Módulo 8 Blbhoteeano
control de COntrol de Gestión de

lider A Pruebas A lider 8 nesgos 8 Pruebas V
calldad A calidad 8
Programador Programador OoOJmentador ~~ramador Programador Programador

1ntegrador 8
Al Al A 81 82 83
Figura 3.11: Equipo de proyecto isomórfico.
Los equipos isomórficos son adecuados para proyectos donde los módulos de
software son relativamente independientes de cada otro.
La mayor desventaja de este tipo de equipo es que puede conducir a

dificultades en la integración de módulos, por problemas de comunicación entre <
z
desarrolladores. :5
"'::;:
<
o
b.2.- Equipo de proyecto de especialistas "'
~
"'
En este t ipo de estructura, cada miembro del equipo se dedica a resolver asuntos y
temas relativos a su área de conocimiento o experticia a lo largo de todos los módulos o
tareas a cumplir en un proyecto ( ).
Gestión de Proyectos
Miembro del Miembro del Miembro del

Equipo A Equipo B Equipo C
Módulo A Módulo B Módulo C
Figura 3.12: Equipo de proyecto de especialistas.
La VENTAJA de este t ipo de proyecto es que permite aprovechar al máximo el poten cial
y la eficiencia de cada experto .
166 D IRECCIÓ N Y GESTIÓ N DE PROYECTOS T!C

IN GENIERÍ A DE SOFTWAR E Y GESTIÓN DE PROYECTOS
FUNIBERfj ..........................................................
·.
La DESVENTAJA es que surgen dificultades de integración, ca r encia de unidad en el

módulo (cada expe rto a lo suyo), y problemas de monitoreo y seguimiento con relación
a lo que aporta cada especialista.
b.3. - Equipo de proyecto democrático
Este tipo de estructura de equipo, llamado en ocasiones auto-gestionado, posee una

estructura relativamente informal ( ) . Sus cual idades son :
la toma de decisiones es compartida entre los miembros; y,
la estructura promueve y fortalece la comu ni cación e interacción entre los

miembros.
Miembro del
Equipo B
Miembro del
<
z

z
:::>
z
-O
ü Módulo A Módulo B Módulo C
<
o
z
::>
u.
Figura 3.13: Equipo de proyecto democrático.
La VENTAJA de este tipo de equipo es que trabaja bien para proyectos de desarrollo
mal definidos (i!l-defined) , esencialmente pequeños , donde la innovación y la creatividad
son más importantes que el cumplimiento de plazos estrictos.
La DESVENTAJA es que no son efectivos. Sus fallas surgen debido a que sus
miembros, particularmente personas de gran talento, tiene un alto ego , produciéndose
conflictos más bien persona les. Otro problema con estos equipos es que tienden a
evoluciona r sin un liderazgo debido a su ausencia.
b.4. - Equipo de proyecto de programador líder
Esta estructura se crea para proyectos informáticos de gran complejidad. La estructura ,

propuesta por IBM , es diamet ralmente opuesta a la democrát ica. Con esta propuesta
todas las decisiones importantes son realizadas por un programador líder asistido por

I NGENIERÍA DE SOFT WARE Y GESTIÓN DE PROYECTOS
FUNIBER 6
va rios especia listas realizando funcione s detalladas de apoyo asignadas por el mismo
líder ( ).
PROGRAMADOR LÍDER
Asistente del Programador A

programador líder
Programador B
Bibliotecario
Programador C
Figura 3.14: Equipo de proyecto de líder de programación.
<
z
<
Este planteamiento es conceptualmente similar a un equipo méd ico de cirugía, donde el u
f:¡
>:
cirujano realiza la cirugía sobre el paciente asistido por un equipo de asistentes <
o
o:
w
especializados. En un desarrollo de software el programador líder es respaldado por un "'
:!
asistente de líder, quien trabaja de mane ra cercana al líder y es capaz de reemplazarle. o:
<
~
V>
~
>
En este caso , el gestor de proyecto es un administrador y un proveedor de recursos . z
:::>
z
-o
u
<
c.- Roles involucrados o
z
::>
u..
En un pro yecto existen di ve rso s tipos de roles in vol ucrados , algunos ligadas
directamente al hacer del proyecto y otros como agentes externos.
Componentes considerados en el equipo del proyecto. En el primer grupo

tenemos , tomando de referencia a Pastor :
Jefe de proyecto .
Diseñadores lógicos.
Diseñadores tecnológicos.
Personal de control de calidad y de mejora del proceso de software .
Personal informático enviado por contratistas.
Personal informático impuesto o enviado por la organización cliente.
Expe rtos (sean enviados por la organización cliente o no).
Usuarios.

INGEN IERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
Agentes externos al proyecto. En el segundo grupo se cuenta con la presencia

de:
El cliente.
El dueño.
El promotor (sponsor).
Los f inancieros .
Consultores y asesores.
Audito res.
Directores o jefaturas organizacionales.
Director de Sistemas de Información o Informática.
Proveedores de hardware y software y abastecedores de insumos.
Contratistas .
e
"'u<
o:
~
e
~
w
"'
<
o:
<
....
3 .2. 1 NO SIL VER BULLET. .. ACLARAR EL PROBLEMA DE LA INGENIERÍA DE
;¡;
~ SOFTWARE
::
"'
:::i
.a
~ El software se ha convertido en un elemento clave en la evolución de los sistemas y
o
~ productos basados en computadoras y es una de las tecnologías más importantes del
P mundo actual. En los últimos 50 años el software ha evolucionado de ser una
herramienta para resolver problemas especializados y de análisis de información, a ser
una industria en sí mismo. Sin embargo, aún se tienen problemas para desarrollar
software de alta calidad dentro del tiempo y presupuesto establecido . El propósito de la
ingeniería de software es el de provee r un marco de referenc ia para construir software
de alta calidad.
Actualmente el software ejecuta el r ol de producto y vehículo para distribuir un

producto , a la vez. El producto que distribuye es el más importante de nuestro tiempo,
la información: transforma datos, administra la información de un negocio, o provee una
entrada h acia las redes de info rma ción a nivel mundial.
Junto con el rol protagónico del software , durante los últimos 50 años tamb ién ha
h abi do mejoras dramáticas en lo que respecta al rendimiento del hardware . Sistemas
complejos y sofisticados pueden generar resultados magníficos, siempre y cuando sean
exitosos, aunque representen un problema para qu ienes los construyen .

I NG ENIER ÍA DE SOFTWARE Y GESTIÓN DE PRO YECTOS
FUNIBER
La industria de sof tware se ha convertido en un factor dominante en las economías del

mundo indust r ia lizado. El prog r amador soli t ario ha sido r eemplazado por equipos de
especialistas en software. Sin embargo, aún se generan las mismas preguntas en el
momento de desarrollar aplicaciones complejas:
• Por qué toma tanto t iempo para terminar el software?
• Por qué los costos de desarrollo son t an altos?
• Por qué no se encuent ran todos los errores antes de entregar el producto al cliente?
• Por qué se tarda tanto tiempo y esfuerzo en mantener programas existentes?
• Por qué existe dificultad en medir el progreso mientras el software es desarrollado y

mantenido?
a.- La naturaleza cambiante del software

<
Hasta el día de hoy, existen siete categorías de software que representan un reto para z
<
u
los ingenieros de software: ~
u
"
<
o
• Software de sistema. Es una colección de programas escritos para servir otros

programas. Se caracte rizan por tener una alta interacción con el hardware, gran
*"
:!
<
uso de múltiples usuarios , operaciones concurrentes, distribución de recursos , "'"'

~
>
z
estructuras de datos complejas e interfases externas múltiples. ::>
~u
<
• Aplicación de software . Programas independientes que resuelven una necesidad e
z
;;)
u.
específ ica de negocio. Además del procesamiento convencional de datos, es usado
para controlar las funciones del negocio en tiempo real.
• Software de ingeniería/científico . An t iguamente caracterizados por sus algoritmos

numéricos, estas aplicaciones van desde la astronomía a la vulcanología , o desde la
biología molecular a la manufactura automática . Con el tiempo , los algoritmos
numéricos están siendo reemplazados por aplicaciones interacti vas.
• Software incrustado . Es usado para implementar y controlar características y

funciones para el usuario final del producto o sistema en el que reside, o para el
sistema m ismo.
• Software de línea de producción . Es diseñado pa ra prov eer de una capacidad

específica para el uso de muchos consumido res diferentes.
• Aplicaciones Web . En su fo rma más simple puede ser algo más que un grupo de
archi v os de hipertexto qu e presentan información usando texto y gráficos . Sin
embargo , mientras el e-Commerce y las aplicaciones 828 adqu ieren importancia,
las aplicaci ones w eb han ev oluc ionado en ambientes sofistic ado s que también se

integran con las bases de datos empresariales y las demás aplicaciones existentes
en el negocio.
• Software de inteligencia artificial. Hace uso de algoritmos no numéricos para

resolver problemas complejos que no son disponibles para un análisis
computacional. En esta área se incluyen la robótica, los sistemas expertos, el
reconocimiento de datos, las redes neurales artificia les, entre otros.
Millones de ingenieros de software son reacios a trabajar en proyectos que pertenezcan

a una o muchas de las categorías anteriores. En muchos casos, las aplicac ion es
existe n tes están siendo corregidas, adaptadas o mejoradas, en un ciclo que puede
repeti rse después de años de construido el software.
Otro tipo de retos que han aparecido a través de los años son los sig uientes:
• Computación ubicua . El rápido crecimiento de las redes inalám bricas pronto

establecerá una comput ación distribuida real. El ret o para los ingenieros de
<
z
<
u software se r á el de desa rrollar sistemas qu e permitan comunicarse a través de
~
"< eno rmes redes de datos a computado ras pe r sonales, sistemas empresariales y
~ dispositivos pequeños.
=
:::
e:
<~ • Netsourcing . La World Wide Web se ha convertido rá pidamente en una máqu ina
v;
~ computacional además de un proveedor de contenido. El reto para los ingenieros de
>
z
::>
z
software es el de diseñar aplicaciones simples y sof i sticadas que provean
-o
<
ü beneficios para usuarios finales en todo el mundo.
o
z
:>
u.
r.o • Código abierto . Una tendencia que ha crecido es la de distribuir cód igo fuen te para
"" aplicaciones de sistema , de manera que los consumidores puedan realizar
modificaciones locales. El reto para los ingenieros de software es el de construir
código fuente que sea auto descriptivo, y más que nada, desarro llar técn icas que
permitan al consumidor y al desarrollador conocer los camb ios que han sido hechos
y las consecuencias de su uso.
• La nueva economía . Los desastres financieros causados por las compan1as punto
com a inicios de la década del 2000 ha hecho creer a muc hos que la nueva
economía está muerta. Sin embargo , la nueva econom ía está viva, evoluciona ndo
con lentitud. El reto para los ingenieros de software es el de construi r aplicaciones
que faciliten la comunicación y distribución de producto s en masa, u t i li zando
conceptos que recién se están creando.
b.- La evolución del software
A través del tiempo , es inevitable que el software evol ucio ne . El cambio (referido como
mantenimiento de software) conduce este proceso y ocurre cuando se corrigen errores ,

FUNIBERf~
I NGEN IER ÍA DE SOFTWARE Y GESTIÓN DE PROY ECTOS
se hacen adaptaciones pa r a nuevos ambientes , cuando el usuario so lic ita cambios

funcionales , y cuando se realiza una reingeni ería de la aplicación para modern iza rla.
En los últimos 30 años , Manny Lehman y sus colegas han efectuado análisis detallados
de la industria del software , con el fin de d esa rr ol lar una T eoría Un ificada p ar a la
Evolución del Software . Para ello establecieron algunas leyes úti les para referencia:
• La ley del camb io continuo (1974) . Sist emas e- Type 7 deben ser continuamente
adaptados, o se convertirán menos satisfactorios prog resivamente .
• La ley de la complejidad incrementada ( 1 974) . A medida que un sistema e- Type

ev oluciona , su complejidad también lo hace, a men os que se haya t omado alguna
medida para mantenerla o reduci rl a.
• La ley de la auto regulación ( 1974). La evolución de los sistemas e-Type es auto

regulada con la d istr i bución de productos y medidas de procesos cerca de lo
normal.
<
z
<
• La ley de la conservación de la estabilidad organizacional ( 1 980) . El promedio del ~
5
>:
índice de actividades globa les efectivas en un sistema e- Type en ev olución es <
o
5
invariable sobre el tiempo de v ida del producto 8 . "'
<
a:
<
• La ley de la conservació n de la fa miliaridad ( 1980). A med ida que un sistema ~
¡;;
5
evoluciona, todos los elementos asociados a él deben mantener el domin io de su ::::
z
::l
contenido y comportam ie nto , para poder lograr una evo l uc ió n satisfactoria . El z
-o
ü
cre cim iento incrementa l promed io se mantiene invariable a med ida que el sistema <
o
z
evoluciona. "
u.
,,,.
""
• La ley del crecimiento continuo ( 1 980) . El contenido funcional de un sistema e-
Type debe ser incrementado continuame n te , para mantener la satisfacción del
usua rio durante el t iem po de vi da del sistema.
• La ley del decrecimiento de la calidad ( 1996) . La calidad de los sistemas e- Type

empezará a declinar a menos que los sistemas sean rigurosamente mantenidos y
adaptados a los cambios del ambiente.
• La ley del sistema de (1996) . Los procesos evolut ivos

retroalimentación
co nstituyen sistemas de retroal imentación mu lti nivele s, mul tila zos , y multiagentes
y deben se r tratados como t ales p ara adquirir una mejo ría significativa.
7. Los sistemas e-Type son software que se han implementado en un contexto computacional del mundo real y por lo
tanto evoluciona con el tiempo.
8. Esta ley establece, en términos más coloquiales, que -por ejemplo- cuando un determinado software se implanta en
una organ ización con el objetivo de realizar una serie de tareas se asume que las veces que se realizan estas tareas
es invariable en el tiempo, y por lo tanto, independiente de las actualizaciones o modificaciones del software, el
volumen de su utilización será constante en los mismo términos que las veces que repiten las tareas.

IN GENI ER ÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
FUNIBERfi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .irml. . . . . . . . . . . . . .- -
Las reglas antes descritas son una parte inherente de la realidad de un ingeniero de
software. Es por ello que se deben implementar prácticas y técnicas que conduzcan a
mantene r la calidad mientras el software evolucione.
3.2.2 GESTIÓN DE PROYECTOS EN INFORMÁTICA
Sin se r una bala de plata, la gestión de proyectos en informática ha cobrado relev ancia
frente al reto del cambio de siglo (pro blema conocido como Y2K), el ca mbio al euro o la
simple globalización. Ante ello se exige que un gesto r de p royectos sea capaz de
abordar cualquier tipo de proy ecto informático, manejando equipos mu ltid isicip lin arios
en su pluralidad curricular, cultural, socia l y psicológica.
No obstante , la gestión de proyectos desde la perspecti v a forma l del PMBOK es una

desconocida en la Informática. A pesar de esto último, la Ingeniería de Software intenta
proveer métodos , técnicas y herramientas de desa r ro llo , dentro de las cuales se
<
z
<
u
incluyen algunas orientadas o consideradas de la gestión . En tal sentido , este apartado
~ presenta el significado que adquiere la gestión de proyectos en informática.
:E
<
o
~
<
o:
<
t:
3.2.2.1 Los problemas comunes en Informática
"'~
=:
z
::> Para entender el rol de la gestión de p r oyectos en la Informática es conven i en t e
z
-O
ü
<
comenza r comprendiendo los problemas qu e existen en los pro y ectos informáticos .
e
z
~
a.- Tipos de problemas comunes
Podemos deci r que hay t res 'problemas comunes', dos de ellos habituales y, un t ercero ,
de índole social.
a. 1 .- Necesidades no satisfe c has o no identificadas
En el caso de las necesidades no satisfechas o no identificadas, el error puede aparece r

debido a que se omiten datos durante el desarrollo del proyecto, es por esto que es muy
impo rtante no saltar ninguna etapa del ciclo de vida de l desarrollo de sistemas.
Otra causa de insatisfacción de necesidades es la mala definición de las expectativas de

un proyecto en sus orígenes , ya que si no están bien definido s los requeri m ientos
máximos y mínimos que el proyecto debe satisfacer desde el comienzo , los
desarrolladores v erán afectado su trabajo por el " síndrom e de las n ecesidad es que
c recen" el cual les deja ra hacer cambios en el proyecto en cua lquier momento s in
detenerse a pensar si esos cambios se rán buenos para el proyecto co m o un todo (por

l NGEN IERi A DE SO FTWARE Y GESTIÓ N DE PROY ECTOS
FUNIBER G
supuesto todos estas modificaciones acar rearan alteraciones en los costos y en los
tiempos de entrega).
a.2. - Los habituales: atrasos y costes
Uno de los rasgos caract erísticos y síntoma de "normalidad informática" es que los
proyectos informáticos se atrasan y se exceden en los presupuestos económicos. Decir
que el tiempo y dinero se duplican, triplican o cuadruplican ya no tiene sentido, es un
hecho y tradición del vulgo . Esto sucede debido a que un proyecto generalmente exige
un estudio de viabilidad en el cual muchas veces no se incluyen datos completamente
precisos de la cantidad de recu r sos que cada tarea consumirá , y es en base a este
estudio que se hacen estimaciones de los recursos totales que el proyecto va a
necesitar.
En cuanto al atraso , generalmente se debe a que los gestores del proyecto no son
buenos gestionando los tiempos de entrega de cada una de las diferentes tareas que el
proyecto involucra, es así que cuando tienen un retraso no son capaces de alterar los
<
z
plazos de entrega finales creyendo que podrán recuperar el tiempo perdido. En general <
u
esta es una muy mala política de trabajo porque no siempre es posible acelera r otras ~
"<o
tareas para ahorrar tiempo en la entrega final. ;:¡
"'
::
""!::
Por ejemplo, Glass señala que el 40 % de los proyectos informáticos son cancelados por
"';:¡
estos excesos; mientras , un 33 % se enfrentan a cambios de tiem po , costes y alcance. :":
z
:::i
z
·O
Sin embargo , esta imagen no es propia de la informática , por ejemplo Ribera, nos u
<
e
z
muestra algunos ejemplos dignos de mención: "'
u.
G
• El proyecto del Opera House de Sidney pasó de 7 millones de dólares a 107

millones de dólares.
• El proyecto de desarrollo del avión F-22 Raptor que ha superado un cos t e del billón
de dólares.
• El proyecto del túnel del Canal de la Mancha , cuyo coste inicial de 7 ,5 billones a
llegado a los 17 ,5 billones de dó lares, y se terminó en 1994 en lugar de 1992.
Pero no es necesario pensar en esas grandes empresas humanas, cuya complejidad

puede justificar cualquier superación de estimaciones. Se puede pensar en el simple
atraso en la construcción de un edificio, algo tan habitual y corri ente que se nos pasa
desapercibido. Lo que queremos decir es que fuera de la Informática los proyectos
también se atrasan y cuestan más caros por motivos tan diversos y v ariopintos como
los que se escuchan en informática.

I NGEN IERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
FUNIBERf1 .......................................................
Lo que es preocupante es que dentro de la Informática estos problemas se manifiestan

tanto a gran escala (como los ejemplos dados por Ribera ) como a escala "case r a" ,
viéndose afectado por tanto todo el tejido socio-económico, incluyendo aspectos como
el crecimiento org anizaciona l, los planes de empresa, o el presupuesto de una PyME.
a .3 .- El social: la imposición de los resultados
Aparte de esos comunes problemas de tiempo y coste , está en lo que podría llamarse el
problema de 'adopció n por dec reto'.
En muchas ocasiones los productos informáticos son impuestos por las jerarquías
administrativas sin una asimilación y / o aceptación de l personal o los traba j adores .
Según ciertas culturas este tema resulta conflict ivo y un problema a ser resuelto. Un
caso de cultura que rechaza esta situación es la escandinava , así , livari y Lyytinen
destacan que los productos informáticos son art efactos surgidos y definidos por
quienes les usarán, los trabajadores.
<
z
<
u
~
El problema es básicamente de los princip ios ligados a la historia de la ingeniería , donde
z
<
o ella busca ser gen eradora de soluciones a las necesidades de la humanidad , aportando
~
"' artefactos con un valor agregado y márgenes de ganancia social siempre positivos para
<
"'<>- el 'homb re de la calle' .
u;
~
~
z
:::> Esta visión se contradice con la costumbre informática de imponer soluciones según el
z
·O
ü último avance en el área, la última tendencia o lo que sencillamente hay que tener. Al
<
o
z
::>
final, ocurren ajustes de trabajo de índole tayloristas que impone n aparentes mejores
u.
niveles de eficiencia , confundiendo: procesos de negoc ios más eficientes con aumento
de velocidad computacional , y / o mejoras de la eficacia en base a nuevas práct icas
labo rales con simples automatizaciones de prácticas de trab ajo.
En una sociedad del conocimiento este tipo de act itudes no son permitidas , pues es
necesaria la part icipación libre y colaborativa de t odas las personas involucradas en un
proceso de construcción de productos info rmáticos, sean tanto diseñadores de sistemas
como usuarios finales .
b.- Las consecuencias de los 'problemas comunes'
Hoy en día los proyectos informáticos se asumen que son un riesgo a corre r, lo cual no
evita que al final de un proyecto info rmático se puedan plantear tres consecuencias:
b. 1 .- Desconfianza en el producto
Una aparente desconfianza en el producto se nota en exp re siones ta les como: " al final
se hizo a la ligera ", "sencillamente ... se remató" , "a p ága lo , f unc ionará cuando lo
DIRECCIÓN Y GESTIÓN DE PROYECT OS TIC 175

lNGEN!ERfA DE SOFTWARE Y GESTIÓN DE PROYECTOS
prendas" , o sencillamente " bueno , al f ina l en software siempre salen cosas que algo
hacen en pantalla" .
Si bien pueden ser sencillamente comentarios de paso, si es cierto que en los resultados
informáticos en la forma de softwa re , in fr aestructuras y / o sistemas de información,
todavía no es posi ble er radicar el oscu rantismo de una profesión que entrega productos
con fun cionamientos en ocasiones misteriosos y plenos de 'bugs'.
b.2.- Desconfianza en la profesión
La desconfianza en la profesión la sufren los practicantes de la informática cuando se

les pide evaluar un producto, calcular un coste o sencillamente dimensionar algún
resultado. No se le puede pedir a un ingeniero informático calcular o estimar un
producto cuando las actu ales herr amientas no son seguras ni fiables. Esto ocurre en
otras disciplinas , pero sencillamente la informática está, diríamos aún en pañales,
llevando a justificar como válido el multiplicar por dos , al menos, los costes y los
tiempos planificados. En extenso, la consultoría informática puede llegar a se r un fac t or <
z
<
u
negativo al momento de la promoción profesional. ;;¡
~
<
o
~
b .3 .- La crisis del usuario CI)
Pero hay otra consecuencia relevante . No es una desconfianza en lo que resulta del
trabajo informático o en lo que produce la formación informática, es la crisis del usuario.
Se debe aceptar que la sociedad occidental postmoderna es una sociedad del riesgo. No
una soc iedad que vive experiencias al límite , sino una sociedad que acepta en
situaciones concretas márgenes de riesgo como algo cotidiano y éticamente aceptable.
Esta concepció n del mundo es ideal para la Informáti ca, donde aún los proyectos son
empresas de riesgo . No solamente en el ámbito de desarrollo (por ejemplo un software)
o de adaptació n (por ejemplo aplicacio n es ERP) , sino en el ámb ito de n egocios (por
ejemplo en e -Business). Es más, puede r esulta r inc l uso curioso que frente a los
problemas comunes de atrasos , sobre cos t es y produ ctos no ace ptados , los clientes
acept an este fenómeno.
Pero no por estar en una sociedad que tolera el riesgo , la profesión info rm ática deba
encaminarse hacia caminos donde la falla, el error y la incerteza sean aceptables y aún
más, rasgo distintivo de la profesión.

Hablamos de una crisis del usuario en analogía a la crisis del software 9 (según Gibbs).
Mientras la última pregonaba los problemas de construir softwa re, la primera alude a los
problemas de qui en debe sopo rt ar u sar los r esul t ados de los proyectos info rmáticos.
Esta cr isis se debe a que quien recibe y u sa el producto info rmático, que debería estar
mejo r que antes, a veces no lo está tanto, al pasa r, por ejemplo , un proceso manua l
robusto y pr obado , por u n softwar e co n fallas y un sistema de man t enimien t o
defic iente.
Lo importante es que la visión escandinava de pensar en el t rabajador debe estar

presente. Pero si a alguien no le gusta esta concepción del trabajo profesional, se puede
toma r la línea clá sica de gestión de la calidad , la cual señala que es impo rtante da r
prioridad al sistema requirente.
En una consultoría informática esto requ iere el fuerte compromiso de resolver

prob le mas, sensibilizándose el profesio nal de los problemas del usuario y at end iendo
siemp re a que su misión es resolver un problema sin añad ir otros .
<
z
 problemas de gestión.
z
=>
z
·O
ü c .1 .- La nat uraleza del product o
<
o
5
u.
Según Jurisson y Pressman, el pr i ncipal producto informático, el software, se
caracte riza por se r:
intangible;
invisible;
- complejo;
volátil de requerimient os;

- socio-técnico ; y,
- difícil de medir.
A continuación hablaremos de cada uno de ellos.
Intangible. Pues claramente el resultado es un software el cual no se puede

mo ldear manualmente , sino menta lmente , sin restr icciones de leyes físicas o
9. Identificada con entregas tardías, presupuestos superados con creces y fallas en satisfacer las necesidades de los
clientes.
D IRECCI ÓN Y GE STI ON DE PROY ECTOS TIC 177

FUNIBER
límites del proceso de manufactura. Lo cual , además , produce que sea difícil
detectar y prevenir errores.
Invisible . Pues la solución que se provee es básicamente un funcionamiento que

toma prestadas funcionalidades de un hardware , sin que el hardware sea
componente del sistema software. De hecho el hardware, incluso otro software
o persona, solamente en tiempo real, y según sus presentes condiciones de
operación ga rantizan o no prestar lo que el software les pida.
Complejo . Pues un desarrollo involuc ra muchas acciones y el producto

comprende también muchas tareas , cuya comprensión supera las capacidades
humanas.
Volatilidad de requerimientos. Lo cual es sencillo de detectar por cuanto el

desarrollo está siempre sujeto a presiones de cambio y que por ser software , el
cambio es un estilo de vi da.
Socio-técnico . Un producto informático no tiene sus fronteras en la pantalla ni

en un usuario que teclea , o incluso un cliente que paga. Un sistema de
información involucra varias piezas relacionadas conformando un sistema de
trabajo donde encontramos que operadores manteniendo el sistema , software <
z
siguiendo algoritmos y hardware aportando infraestructura, interactúan con :
<
informático es sólo hardware y software es un error, salvo excepciones muy o
conc retas, pero la generalidad no muestra esta realidad, menos cuando se ~
desean sistemas que soporten una solución e-Business.
Difícil de medir. Por las otras cualidades señaladas y por la juventud de la

Informática, se hace difícil tener hoy en día tener técnicas efectivas que
permitan medir, y las que existen están aún en calibración.
c. 2. - Problema s de gestión
Entre los problemas de gestión aparecen mencionados entre otras cosas:
• objetivos y especificaciones pobremente definidas;
• falta de un plan de proyecto;
• presupuestos y plazos poco real istas; e
• inhabilidades de relaciones sociales.
Haciendo una re vi sión de la literatura encontramos diversos problemas de gestión, los

que se muestran comparativamente en la . Los problemas de gestión se
presentan clasificados según las áreas de conocimiento de gestión de proyectos del
PMBOK y paralelizados según ciertas similitudes entre ellos .

FUNIBERÍ~
IN GEN I ERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
. . . . . . . . . . . . . . . . . . . .¡¡¡¡¡z¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;11iiiiiiiij¡:;::::=;:i
Para la lista de McConnell y Purba et al., entre paréntesis se ind ica la categoría en que
estos autores clasifican sus problemas. Debemos recalcar que lo most rado en la tab la
es meramente referencial y no comprende todo el domin io de problemas existentes.
'~~.....::.~:." ... •.
ilto].¡·:~\
·:-·'-''111:1•1 tl:i ·-~~ i\"J;~~r ~, , .." . ~-~~:·:, ._..(:_
,,_,!J•1t1:11:1 __ •"• c..;-lh, ll,l:::iWL' ::?..}.~ \,,' :1•l:Jtlúlll ..
~~·~,'(~
.'.
'"v rct::1...,.
tl
tl ~ : ~-"'.> .
~·-~"··-:o:'
. ;
~.
. i
Exceso de
requerimientos
(producto)
Incapacidad de los usuarios en
Planificación Usuarios que Poca cla ridad en los
comunicar requerimientos
resisten requerimientos
(ele mento humano)
Abandono de tiempo Promotor está
en el inicio (proceso) perdido
Pérdida de tiempo en
el inicio
Polít ica antes que Política organizacional
< (aspectos políticos)
z desarrollo ( personas)

...u
·O (proceso)
z < Convergencia
::J
z
a::
-O
\!) prematura o
ü w
< 1- Ejecución excesivamente
e
z
"
u.
...zw frecuente (proceso)
o Falta de participación Equip. políticos (aspee. políticos)
z del usuario (personas) Política indiv. (aspee. políticos)
...1-
·O
Añadir más personal a
VI
w un proyecto retrasado
\!)
personas)
Mejores
Tiras y aflojas en la prácticas y Mala gestión de las fases de
Mala especificación
negociación (producto) lecciones son desarrollo (elemento humano)
olvidadas
Pruebas insuficientes
(error humano)
Falta de control
automático del código
fuente (tecnología)
Cambios son
Cambios en las prestaciones Falta de control de
pobremente
Control (producto) cambios
gestionados
Cambios
Incapacidad de acomodar cambios
en las
a requerimientos de negocios
necesidades de
(elemento humano)
negocio
DIRECCIÓ N Y GESTIÓ N DE PROY ECTOS TIC 179

INGEN I ERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
FUNIBER
....-..... ·' '/ •·:· ·. ,-.,·., ,., i) .} ' . -·

'.~~
1 '1t]l t)::I •.
!.:J:h :1 •::i .:. Utl:I

,,.
1.:. ••tl.' l.'l ::UL ~~ e{ ..
..
1:4::itJ.:.ll•L
:l.., ·,.
~~ 1 ..-J}
~
<
H ! 1 ltl.'I
. ~ ~
~ t-IJ) ~
Desarrollo orientado a la
investigación (producto)
Iniciación Falta de un proyecto
efectivo del proyecto
(personas)
Gestores no Incapacidad de los usuarios en
comprenden las comprender las implicaciones
necesidades de de los requerimientos de
los usuarios negocios (elemento humano)
Pla n1ficación insuficiente Alcance mal Mala planificación (elemento
(proceso) definido humano)
Expectativas poco Expectativas poco realistas
rea listas (personas) (elemento humano)
w Síndrome de la panacea
u
z Planificación
(tecnología)
:
<
z prácticas y o
·O
.... lecciones son ~
1-
V) olvidadas
w
\!)
Sobreestimación de las
ventajas del empleo de
nuevas herramientas o
métodos (tecnología)
Limitaciones técnicas
Ejecución Políticas de la unidad

informática de la organización
(aspectos políticos)
Mejoras
prácticas y
lecciones son
Control olvidadas
Control insuficiente de la
directiva (proceso)
180 DIRECC IÓN Y GESTION DE PROYECTOS T IC

FUNIBERfJ
------------------------------------
·}~.u ...;:.1:u1:i•>1.:.•·tfií:I
..
.(C'l:¡.."11111.' >·~~.'.!:"'.'?
.- ·'- -:"" --·----~ .... ,..~.~~-
'' "t;•º·--~ .•.:. ••••U1~1 :1 ... - .• , ··
. ·-·· '~{-·~,,..._:.i:, '<'A.•"·"'' "'--~¡y,.
:tí;~ --
l.:111'· \.."\.."t
,- e
., . 11 • .,:.f •\ -
,_
1·• ::1•1.:.11•1,;
Tiempo y
Omitir tareas necesarias
presupuesto
en la estimación (proceso)
inadecuado
Estimaciones
Estimaciones erradas
erradas
Planificación
GESTIÓN DE No se hace
COSTES estimación
Escatimar en las
actividades iniciales
(proceso)
Control Recursos insuficientes
(elemento humano)
Tiempo y
presupuesto
Omitir tareas necesarias
Pla zos irreales inadecuado.
en la estimación (proceso)
Planificación Estimaciones
erradas
GESTIÓN No se hace
DEL TIEMPO estimación
Planificar poniéndose al
día más adelante
<
Control (proceso)
O'
<
....
;; Programa a destajo
:;; (proceso)
>
z
:::> Se carece del
z
·O personal con las
ü Planificación
<
e habilidades
z
...
::>
r.-
GESTIÓN DE
adecuadas
"" LA CALIDAD Oficinas repletas y

Ejecución
ruidosas ( personas)
Escatimar en el control de
Control
calidad (proceso)
Ilusiones (personas)
Motivación débil Se carece de
Planificación Insuficientes
(personas) persona l con
habilidades técnicas
Personal mediocre habilidades
(elemento hum ano)
(personas) adecuadas
Empleados problemáticos Pobres desarrolladores
incontrolados (personas) (elemento humano)
GESTIÓN DE
RECURSOS Desarrolladores Política individual
HUMANOS meticulosos (producto) (aspectos políticos)
Hazañas (personas)
Ejecución
Fricciones entre los
clientes y los
desarrolladores (personas)
Falta de participación de
los implicados (personas)

,, • •'-'••t1::1 ".F 7iJ:n; ~ .~ J.11 tl:al'C'I ~,•1t 1 :1 ·l.\ lo• ti.' I; 1:;?':!.1 ··1~ . . ,, .. ~"'\..itN 1• '°· !.;Hl•l:"GEa •. l·l~ t'l .' ll•L
Insuficientes
habilidades técnicas
(elemento humano)
Planificación
Estrategia de
implementación débil
(elemento humano)
Ejecución Mejores
prácticas y
lecciones son
olvidadas
GESTIÓN DE Se carece del
COMUNICACIONES personal con
Control
las habilidades
adecuadas
Tiras y afloj as
en la
negociación
(personas)
Cierre
Fa lta de
participación del "'z
usuario "'u
(personas) ~
:i:
Planificación Gestión de
"'o
~
riesgo "
insuficiente
(proceso)
GESTIÓN DEL RIESGO
Tiras y aflojas
en la
Control
negociación
V
( personas) <
o
z
:::>
u.
Incapacidad para
Fallos en los ~
tratar con contratistas "'

Planificación contratados
y vendedores
(proceso)
(elemento humano)
Incapacidad para
tratar con contratistas
Ejecución
GESTIÓN DEL y vendedores
APROVISIONAMIENTO (elemento humano)
Recursos insuficientes
Control
(elemento humano)
Cierre Se carece del
personal con
las habilidades
adecuadas
Tabla 3.2. Diversos tipos de problemas de gestión clasificados según el PMBOK.
182 DI RECCIÓN Y GESTIO N DE PROYECTOS TIC

I NGEN I ERÍA DE SOFTWARE Y GESTI ÓN DE PROYECTOS
_ _ _ _ _ _ _ _ _ _ _ _ _ __ __ _ _ _ _ _imll_ _ _ _ _ _ _ _ _ __ _
FUNIBERfJ
3.2.3 FORMAS DE EVITAR ESTOS PROBLEMAS
Para evitar todos estos pos ibles problemas, se debe tener al mando de l proyecto un
buen gestor que conozca muy bien las herramientas de diseño y aná lisis de sistemas
además de una buena formación en las funciones básicas de dirección.
El director de proyectos no es simplemente un analista experimentado que se h ac e

cargo del proyecto, sino más bien debe aplicar un conjunto de técnicas y conocimientos
diferentes de los que aplica un analista.
Las funciones básicas de un gestor de proyectos han sido analizadas y diseccionadas

por teóricos de la gestión durante muchos años . Entre estas funciones , se inc lu y en la
planificación , la selección de personal , la organización, la definición de calendarios , la
dirección y el control .
a.- Planificación de las tareas de proyecto y selección del equipo de

z
< proyectos
<
u
~
:E
<
Un buen director siempre tiene un plan . El director evalúa las necesidades de recursos y
o
::; formula un plan para llegar al sistema objeto. Ello se basa en el conocimiento que tiene
"'<
;;; el director de los requ isitos del sistema objeto en cada momento de l desarro ll o . Un plan
<
t:
"' básico para el desarrollo de un sistema de información es el sum inistrado por el ciclo de
::;
>
z
:;;;¡
vida del desarrollo de sistemas. Muchas empresas tienen su propio ciclo de vida
z
~
estándar, y algunas de ellas tienen también normas sobre métodos y herramientas que
u
<
e
z han de usarse.
.;:
Así ha de planificarse cada una de las tareas requeridas para completar el proyecto:
• ¿Cuánto tiempo se requerirá?
• ¿Cuántas personas serán necesarias?
• ¿Cuánto costara la tarea?
• ¿Qué tareas deben terminarse antes de empezar otras?
• ¿Pueden solaparse algunas de ellas?
Estas cuestiones son propias de la panificación y pueden resol v erse con la ay uda de
herramientas cómo PERT o CPM. Estas y otras herra m ientas pueden re v isarse con
detalle más adelante en este documento.
A nivel de proyecto , estas cuestiones pueden resol v erse hacie n do una se lecc ión
correcta del equipo. En esta situación , los gestores de los proyectos son ,
frecuentemente , los encargados de seleccionar y deben tener m uy en cuenta los
DI RECCIÓN Y GESTIÓN DE PROYECTOS TIC 183

FUNIBER~~
I NGEN I ERÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
conocimientos técnicos y de empresa que pueden ser necesarios para terminar un

proyecto con éxito y que cada rol del proyecto debe dominar. La clave de esta misión es
saber elegir adecuadamente a las personas que habrían de desarrollar las tareas
requeridas e identificada como parte de la planificación de proyecto . Junto a la
selección es crucial el diseño de la estructu r a organizacional y la morfología del
proyecto, temas que se profundizan en otros apartados de este documento.
b.- Organización y definición de calendarios para el proyecto
Dados el plan y el equipo de proyecto, el gestor de proyectos es el responsable de la

organización y la definición del calendario del mismo. Los miembros del equipo de
proyecto deberán conocer su cometido y sus responsabilidades concretas, así como su
relación de dependencia con el respecto al gestor del proyecto.
El calendario de proyecto debería desarrollarse con un conocimiento preciso de los

requisitos de tiempo , las asignaciones de personal y las dependencias de unas tareas
con otras. Muchos proyectos tienen un límite a la fecha de entrega solicitada . El gestor <
z
<
L;
debe determinar si puede elaborarse un calendario factible basado en dicha fecha . Si no ~

>:
<
fuera así, debería retrasarse el limite o reajustarse el ámbito del proyecto. o
..
~
c.- Dirección y control del proyecto

Una v ez iniciado el proyecto , el gestor del proyecto se convierte en su máximo
responsable . Como tal , dirige las actividades de l equ ipo y hace evaluaciones del avance
del proyecto. Por consiguiente , todo gestor de proyectos debe demostrar ante su equipo
cualidades de dirección , como son saber motivar, recompensar, asesorar , coordinar,
delegar funciones y reconocer el trabajo de los miembros de su equipo . Además , el
gestor debe informar frecuentemente del avance del proyecto ante sus superiores.
Tal v ez , la función más difícil e importante del gestor sea controlar el proyecto. Pocos
planes hay que puedan llevarse a la pr actica sin problemas y retrasos. La labor del
gestor de proyectos es hacer un segu im iento de las tareas, los plazos , los costes y las
expectativas , con el fin de controlar todos los estos elementos. Si el ámbito del
proy ecto tiende a crecer , el gestor del mismo debe tomar una de c isión : ¿habría que
reducir el ámbito del proyecto para respetar el presupuesto y los p lazos , o revi sar dicho
pre supuesto y dichos plazos ? El gestor del proyecto debería ser capaz de presentar
alternativ as , y sus implicaciones, a los plazos y presupuestos para saber responder a las
ex pectati v as.

I NG EN I ERÍA DE SOFTWARE Y GESTI ÓN DE PROYECTOS
d.- Estimación del trabajo a realiza r y del tamaño del software
El trabajo en un proyecto se estima calculando y evaluando las tareas a rea lizar, lo cual
requiere estimar el trabajo a realizar en el proyecto y estimar el tamaño del softw are.
d .1 . Estimación del tama ño del trabajo a realizar
Todo proyecto debe conocer las tareas a realizar. En est e sentido debe emplearse una
herramienta como la WBS (cuyo detalle se presenta más adelante ). Un WBS permite
conocer el trabajo a realizar en un proyecto mediante un proceso de descomposición
sucesivo de tarea o unidades de trabajos. En los pro y ect os de software , no es una
herramienta muy popular pues suele cercernarse o dejarse el trabajo a realizar en t areas
genéricas como análisis , diseño o mantenimiento -por ejem p lo-, pero es cierto que cada
proyecto define tareas muy concretas para estas tareas ge nerícas.
d.2 . Estimación del tamaño de l software

<
"<
u Independiente de la estimación del trabajo a realizar por unidad de trabaj o, deriv ado de
§
"
< un WBS, está el tamaño del software, lo cual ayuda a decidir respecto del persona l
o
5 necesario para cumplir cara tarea. La calidad de esta estimación infl uye directamente en
"'
las estimaciones del coste y de la programación , aparte de ser la más compleja. Cuando
se hace de manera pobre , induce a proyectos que superar costes y prog ramaciones.
z
·O A continuación mediciones de tamaño de software habitual m ent e empleadas 10 : líneas
ü
<
o de código, puntos de función y COCOMO .
"
:l
u..
Q
• Líneas de código. La técn ica de líneas de código requiere estimar el número de
líneas de código fuente por simple analogía. Esto da " una idea " del trabaj o a
realizar. Su ventaja es l a simplicidad del conteo . Su problema es lo que s e
considera como línea de código (por ejemplo, una instrucción completa o una línea
escrita ).
• Puntos de función. El análisis de puntos de función , por otra parte, no requ iere
conocimiento previo del código fue n te. Se basa en una medic ión de la
funcionalidad del negocio. El número de puntos de func ión es determinado de la
suma de entradas, sal idas, consultas , ficheros maestros e in terfaces del sist em a a
construir con otros sistemas. Este primer conteo es ajustado segú n la complej idad
técnica y factores medioambientales para arribar a una estimació n m ás precisa de
puntos de func ión . De esta manera , los puntos de f un c ión conduce n a u na
10. COCOMO. Cálculo on/ine.

Enlace web: httD: f/www .oeí eui. uDm. es' A,s 1gnaturas/Pioformat'cos/ f'che ros/software1opcion3/COCOtvlOI. htrnl
COCOMOII. Enlace web: http:t/~unset.usc.edu'csse/research/COCO~~OIJ!cocomo ma1n.html
IFPUG. !FPUG: ! nternationa/ Function Point Users Group. Enlace web: www.jfrug.org/
DIRECCIÓN Y GESTIÓN DE PROYECTOS T IC 185

I NGENIERÍA DE SOFTWARE Y GESTI ÓN DE PROY ECTOS
FUNIBERfj
estimación más confiable e independiente de los lenguajes de programación. Su

ventaja es que permite trabajar a nivel funcional del producto. Su desventaja es que
requiere tener actualizados datos históricos .
• COCOMO (COnstructive COst MOdel) es un modelo matemático de base empírica

utilizado para estimación de costes de software. Incluye tres submodelos , cada uno
ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el
proceso de desarrollo del software: básico , intermedio y detallado. Pertenece a la
categoría de modelos de subestimaciones basados en estimaciones matemáticas.
Está orientado a la magnitud del producto f inal , midiendo el "tamaño" del proyecto ,
en líneas de código principalmente . Existen dos versiones, COCOMO y COCOMO 11
(v ersión más completa y detallada ). Su ventaja es que es un estimador que incluye
y considera aspectos amp li os del proyecto. Su desventaja es seleccion ar el modelo
COCOMO adecuado para estimar .
3.2.4 ESTADOS DE UNA MALA GESTIÓN DE PROYECTOS <

z
<
~
5
Los errores mostrados en la y muchos otros más , ocurren y han sido "<o
reportados profusamente en la literatu r a. No obstante , se han podido determ inar
.5
<
;;;
algunos estados que indican una gestión de proyectos inefectiva o de que es prudente <
~
;¡;
plantearse usarla. Estos estados de un proyecto son: 5
:::z
:::J
z
-o
• modo ajustado (crunch mode) ; u
<
o
z
::>
u.
• marcha mortal (death march) ; y ,
• fuera de control (runaway ).
3.2.4.1 Modo ajustado
El modo ajustado , para Glass, describe un proyecto que se encuentra extremadamente

ajustado a la p rog r amación . Se habla que existen fuertes presiones que sienten los
participantes del proyecto. Es el estado cuando el proyecto anda por los límites del
programa de trabajo , más bien superándolo .
En este estado , dentro del proyecto informático comienza a notarse que:
" las semanas ti enen siete d ías y los días 24 horas " ;
" los días son cortos y las noches largas";
empiezan las primeras fugas;

FUNIBERf~ ...........................................
INGENIE RÍ A DE SOFTWAR E Y GESTI ÓN DE PROY ECT OS
hay una 'ralentización' de la mot ivación;
se suceden las re-planificaciones de fo rma frecuente;
etc.
3.2.4.2 Marcha mortal
La marcha mortal, según Glass , describe un estado en que el proyecto tiene una
programación difícil de conseguir. Se habla que "hay olor a fracaso " ("esto huele mal")
en t re los pa rticipantes. Para Yourdon, un proyecto en marcha mortal posee una
valoración de riesgo de falla sobre el 50 por ciento (incluyendo riesgos técnicos, del
personal, legales, políticos, etc. ).
Según Ribera este estado es un Modo Imposible de t rabajo debido a que:
"El plazo es infe rior a la mitad de lo que racionalmente se precisa";
" El personal asignado es inferio r a la mitad que habitualmente se asignaría a un

proyecto de estas ca racterísticas";
:!
" El presupuesto se ha recortado a la mitad", y,
a:
<
,__
'"~ "La funcionalidad, requisitos, y otros aspectos técnicos son superiores al doble
>
z
de lo normal".
:::>
~
ü
<
El mismo Ribe ra acota, que es estas situaciones surgen preguntas como: "¿Qué hace un
o
z
::>
u..
chico como yo en un proyecto como éste" o "¿Cómo puedo sobrevivir a este proyecto
·~ sin perder mi salud física y mental y mi dignidad?".
3.2.4.3 Fuera de control y escalada
Un proyecto fuera de control, o "Runaway" , describe un estado o un estado de cosas

manifestadas cuando un proyecto está cerca o después de su término. Sencillamente, el
proyecto está fuera de sus límites, o ya no tiene límites, hablándose, según Glass , que
el proyecto falló o está pronto a fracasar.
Cuando se está fuera de control, se puede decir que estamos ante una bola de nieve, la
cual resulta de una escalada de errores por motivos, que según Keil y Mixon, se deben a
factores psicológicos , sociales y organizacionales. Estos errores son consecuencia de
una gestión inadecuada, fallida o nula, que pone al personal y especialmente a gestores,
ante una va riedad de problemas que supera sus capacidades de gestión y de resolución
de problemas. Esta situación hace que un error lleve a otro , produciéndose una cadena
creciente, una escalada de problemas de gestión, debido al ca n sancio , fat i ga y
desorientación que supone la tensión de la situación.
DI RECCI ÓN Y GEST IÓN DE PROYECTOS TIC 187

I NGE NI ERÍA DE SOFTWARE Y GES TIÓ N DE PROYECTOS
FUNIBER .
Lo anterior es lo que se llama escalada y romper l a requiere una alta capacidad de

superar el estrés físico y mental que supone un rescate, hundimiento o salvamento
parcial del proyecto.
3.2.5 RAZÓN DE LA GESTIÓN DE PROYECTOS
Se ha dicho que la gestión de proyectos es una manera de hacer frente a problemas y

retos . También hemos añadido los estados de un proyecto que presenta problemas de
gestión. Ahora se presentan razones más concretas que justifican la gestión de
proyectos en un proyecto en general y en un proyecto de base tecnológica . Ellas son:
actuación predi ctiva; y,
recuperación.
3.2.5.1 Actuación predictiva <

z
<
u
..,"'
Para v arios autores , una forma de actuar predictivamente en los problemas de gestión, l:
<
o
es anticiparse a ellos con una completa y adecuada gestión de proyectos, la cual puede :;:"'
medirse si con la gestión se garantizan alcanzar los siguientes Factores Críticos de Éxito
(planteados por Jurison):
• Objetivos claramente definidos .
• Apoyo claro y total de la dirección.
• Presupu esto adecuado y realista.
• Programa coherente , racional y realista.
• Participac ión y confianza real del cliente y usuarios .
• Buen liderazgo del proyecto.
• Re v isiones continuas , constructivas y positivas del proyecto.
• Gestión y control eficiente y eficaz del cambio .
• Buenas comunicaciones entre integrantes del proyecto.
• Antic iparse y solucionar los problemas que surjan con una gest ión de
contingencia s.
188 DIRECCIÓ N Y GESTIO N DE PROYECTOS TIC

FUNIBERf~~ ..........................................
INGEN I ERÍ A DE SOFTWARE Y GESTI ÓN DE PROY ECTOS
3 .2.5.2 Recuperación
Otros autores señalan que la gestión de proyectos permite determinar el momento y las
acciones de recuperación de un proyecto, igualmente de que estas acciones se lleven
delante de manera adecuada. En este caso se habla de una de-escalación y / o la
convocación de un caballero blanco .
a.- De-escalar
En una de-escalación se toman acciones que permitan superar los diversos problemas
de gestión ante una escalada. Para Ribera recuperarse de una escalada puede ser:
recortar la envergadura del proyecto;
aumentar la productividad mediante mejoras a corto plazo; y /o ,
asumir que el proyecto no terminará a tiempo, atrasar el plan y adoptar medidas

;¡ de control de daños.
<
~
"'
~ Lo que para Glass se traduce en tomar acciones en el siguiente orden de preferencia:
o
~
~ extender las fechas;
<
....
¡;;
~ usar mejores procedimientos de gestión;
~
z
;;;)
z
·O más personal;
ü
"'oz
::> más fondos;
"-
"'
""' reducción en alcance del proyecto;
mejores metodologías de desarrollo;
cambiar tecnología; y,
abandonar el proyecto.
Acciones que, para Montealegre y Keil, no tendrían ningún ef ecto si no se ape la a la

colaboración y cooperación de los participantes involucrados en el proyecto o,
sencillamente , des-institucionalizar el proyecto, dejando la de-escalación como un
problema interno de gestión a superar internamente.
Un ejemplo sería el caso de un proyecto informático al que se le agregan requerim ientos

informalmente (fuera de planificación). Esto produce que no se pueda final izar el
proyecto en los plazos previstos. Ante esta situación, se de-escala. Así, se re-comienza
leyendo los documentos de definición, incluyendo el plan de actividades inicial y los
cambios autorizados, y luego se documentan todos l os pu n tos agregados
D IR ECCIÓN Y GEST IÓN DE PROY ECTOS TIC 1 89

I NGE NIERÍA DE SOFTWAR E Y GESTIÓ N DE P ROY ECTOS
FUNIBER l1
extraoficialmente, todo esto para tratar de clarificar cuales son las causas de los desvíos
que llevaron a nuevos requerimientos y además informales. Con esto en mano, se
propone reunirse con las pa rtes interesadas que son claves en el proyecto y acordar qué
se agregaría o quitaría en adelante. Basados en todo esto y en los acuerdos, l as
actividades restantes y los recursos disponibles, se arma un nuevo cronograma. En este
ejemplo , esta situación que permite recuperar el proyecto , debe considerar el análisis del
presupuesto para ver si alcanza o no y prever nuevas fuentes de financiamiento.
b.- El caballero blanco
Una forma posible de superar los problemas de gestión es contratar a un experto en

sal v ar proyectos, aquella persona milagrosa que viene a sal v ar todo mal func ionamiento
y a intentar recuperar el proyecto: el caballero blanco (white knight).
En este tipo de solución debe considerarse la asesoría y la consultoría en proyectos

como un medio válido de conseguir algún caballero blanco.
<
z
<
Un ejemplo de este caso sería un proyecto informático descontrolado, donde cada ~
"'u
:r
acción no concreta en nada específico y tampoco se mantiene el orden interno . La <
o
contratación de un interv entor externo, sea un jefe de proyecto específico o una "'
w
"'
<
;;;
consultora organizacional , como si fuera un caballero blanco, quien se posi c iona como <
t:
VI
líder con poder suficiente para ordenar y organizar el proyecto. Se debe reunir con cada ::s
>
z
una de las partes afectadas e involu c radas y retomar cada requerimiento del proyecto =>
z
<>
para estudiar su estado de avance . El problema que puede surgir es el rechazo por parte u
<
o
del equipo o stakeho/ders del proyecto al caballero blanco , motivo por el cual se debe z
"
LL
seleccionar en muchos casos a alguien con prestigio y reconocimiento .
190 DIRECCIÓN Y GESTIÓ N DE PROYECTOS TIC

INGENIE RÍA DE SOFTWARE Y GESTIÓN DE PROYECTOS
OResumen
<
z
:
<
o
.."'
~
VI
~
>
z
:;)
z
·O
ü
<
o
z
"
"-

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROY ECTO E-BUSINESS
Ca 't o 4
EJEMPLO, DE PROYECTO
TECNOLOGICO:,
IMPLANTACION PROYECTO
::o:
<
1-
¡¡¡
~
E-BUSINESS
::.z
::>
z
o
ü
<
o
~
- Exponer una metodología e-Business como forma de mostrar un proyecto tecnológico en su dimensión de
negocios y tecnológica.
- Conocer una metodología de implantación de una solución e-Business.
- Conocer y describir las etapas en la implementación de una solución e-Business.
Un proyecto e-Business tiene dos dimensiones, una de gestión y una de construcción .

Mientras la dimensión de gestión puede considerarse genérica, la de construcción es
más específica al dom inio técnico de l proyecto.

E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-BUSINESS
FUNIBER
Este capítulo presenta la dimensión de construcción bajo la forma de una metodolog ía

de implementación de un proyecto e-Business. Esta implementación toma la iniciativa e-
Business como idea generatriz y la transfo r ma en una propuesta coherente con la
organización y sus procesos y su estrategia. Esta propuesta se sustenta en una solución
informática donde debe te n er cabida una arquitectu r a e-Business y una ser ie de
sistemas informáticos e-Business co n struidos a la medida y /o adquiridos desde la oferta
del mercado info rmát ico y e-Business ( ).
PROYECTO E-BUSINESS
Gestión de proyectos
Iniciativa e-Business Aplicación e-Business
1 t
Metodología
n- - - - - - - 1
<
- Sistemas e-Business z

negocios z
existentes :::>
z
-O
Oferta de mercado en u
<
o
soluciones e-Business y z
:>
u..
sistemas informáticos <"
Figura 4.1: Metodología de implementación de una solución e-Business.
Antes de iniciar el esfuerzo de construcción de una iniciativ a e-Business es bueno

preguntarse:
• ¿Cómo podemos t ransformar nuestra empresa en soluciones e-Business?
• ¿Cómo puede ayudarnos el hecho de aprovecha r una solución e-Business a

max im izar el valor de nuestra inversión en tecnología de la inform ación?
• ¿Cómo nos ayudará a reducir los costes y a aumentar los beneficios?
• ¿Existe un con vencimiento simi lar en toda la organización sobre la util idad de una
solución e-Business?
• ¿La transformación de la empresa cuenta con la colaboració n de sus expertos en

negocios y los expertos en tecnología?
194 DIRECCIÓN Y GESTI Ó N DE PROYECTOS TIC

FUNIBER f1; r::=====:::=:==::;:¡::::;!!:i::=. . . . . . . . . . . . . . . . . . . . . . . .- -
EJEMPLO DE PROY ECTO TECNO LÓGICO: IMP LANTACIÓN PROYECTO E-B US INESS
• ¿Se disponen de los expertos necesarios para convertir esta idea en una realidad?
• ¿Tenemos algún modelo de implantación que permita un rápido despliegue?
• ¿Tenemos capacidad de traspasar las aplicaciones a otras plataformas que se

puedan necesitar?
• ¿Se pueden aprovechar las inversiones en los sistemas realizados hasta la fecha?
• ¿Sabemos los sistemas que tenemos?, ¿son ad apta bles?
• ¿Nuestros sistemas actuales ofrecen la disponibilidad que requieren usted y sus

clientes?
• ¿Tenemos cap acidad de gestion ar un ent orn o e-Business de manera

eficientemente?
• ¿Nuestra empresa y prov eedores tiene experiencia en seguridad electrónica? ¿Ha

sido exitosa?
<
"
<
u • ¿Estamos dispuestos al cambio?
~
"'
<
~
w
• Etc.
"'
Son muchas las preguntas que en un pr oyecto e-Business pueden darse. De muchas de
ellas no tenemos respuesta ahora , no obstante es posible encontrar respuestas
siguiendo la metodología de implantación que en este capítulo se propone .
La implementación debe entende rs e como el camino mediante el cual una organizac ión
canaliza sus acciones para explotar las ventajas de la Economía en Red a través de una
estrategia definida . Esta estrategia en muchos casos está ausente en var i as
organizaciones que tienen negocios en y /o sobre la red. Por tal motivo se plantea que es
conveniente tener un camino claro que ayude a obten er l a implementac ión de la
solución e-Business .
Este camino es un proceso genérico que puede y debe ser acomodado a los
requerimientos de negocios y entorno de una organización .
Tal camino surge de un ciclo e-Business compuesto de cuatro etapas ( ) , entre

los cuales no e xiste ningún orden o jerarqu ía. Debe aclararse que no todas las empresas
que util izan soluciones e -Business y han alcanzado el éx ito han empezado siempre por el
mismo punto del ciclo.
D IRECCIÓ N Y GEST ION DE PROY ECTOS TIC 195

EJEMPLO DE PROYECTO TECNOLÓG ICO : IMPLANTACIÓN PROYECTO E-B US INESS
FUNIBER
Transformación
.
Diseñar la Creación de nuevas

estrategia aplicaciones
Obtención
de un entorno .
adecuado
Figura 4 .2: Ciclo e-Business.

<
z
<
~
5
Las etapas son: "'
<
o
~
"'
<
• Transformación . Las emp resas que han alcanzado el éxito en el entorno e-Bu siness
";::
utilizan las posibilidades que ofrecen la Web , las intranets y las extranets pa r a ;:;;
5>
t ransformar los procesos centrales de la empresa. El cambio fundamental es en la z
::o
z
manera de hacer los negocios. Estas empresas tienden a: ·~
u
<
o
z
- ser muy abiertas al cambio de los procesos centrales, y ::>
'-
- tener una visión de cómo dicha transformación puede mejorar la empresa .
• Creación de Nuevas aplicaciones . Consiste en la creación de nuevas apl icaciones

de manera rápida y fácil. Además no exist e la necesidad de reinventar la rueda ;
más bien se parte de los sistemas y las aplicaciones que ya se poseen y /o existan
en el mercado.
• Obtención de un entorno adecuado. En la tercer a etapa, centrada en la obtención

de un en t orno de sist emas adaptables , disponibles y seguros, las empresas deben
establecer una in fr aest r uctu r a de hardwar e y de softwar e que pueda crecer
fácilmente al ritmo de la empresa . Además , debe existi r una gestión adecuada para:
el entorno de redes informatizado que se genera y mantener su seguridad.
• Diseñar la estrategia . El diseño busca capitalizar la información y experiencia

acumuladas y aplicar los nuevos conocimientos confo rme aparecen. Se pretende
que el conocimiento esté al al cance de toda la empresa y cualquiera pueda
comprender lo que implica y significa la solución e-Business .
196 D IRE CCIÓN Y GESTIÓN DE PROYECTOS TI C

EJEMPLO DE PROYECTO TEC NOLÓGICO: IM PLANTACIÓN PROYECTO E-B USINESS
Desde un punto de vista metodológico y de negocios, el ciclo e-Business debe ampliarse

para da r cabida a todos los elementos necesarios que permitan pasar de la iniciativa a la
aplicación e-Business.
En este sentido se deben plant ear las siguientes etapas ( ):
• Definir la estrategia . A rtic ula r una c lara y co nsistente estrategia e-Business acorde
a cómo la organización desea usar los recursos de la red . Implica la creación de una
visión, la determinación de objetivos, el d iseño de una estrategia. T ambién define el
alcance general del sistema e-Business en el soporte de los procesos de negocio.
• Definir la aplicación e-Business . Un conjunto de soluciones potenciales que

permitan implementar la estrategia de negocios, lo cual incluye el análisis de los
sistemas existentes y de la opción de comprar sistemas e-Business existentes.
Igualmente definir una arquitectura que prov ea la infraestructura, servicios de
desarrollo e implantación de aplicacio n es q u e den sopo rte al portafol io de
<
aplicaciones e-Business, el conjunto de sistemas computacionales que dará soporte
z
<
" a los procesos de negocios dentro de la solución e-Business .
"'~
<
~ • Desarrollo y despliegue. Crear un plan técnico que muestre cómo las apl icaciones y
w
" la arquitectura han de ser imp lantadas. Implantar ca da aplicación y refinar la
<
;;:
:: arquitectura y plan táctico basado en las lecciones aprendidas.
"'"'
>
z
::> • Uso y evolución . Esta etapa existe cuando los sistemas e-Business han sido
z
·O
ü desplegados por la organ izació n , lo cua l requiere aprender de su uso y recapitular
<
o
z sobre la experiencia de conseguirlos.
...
::>
Definir Definir Desarrollo y Uso y

estrategia aplicación despliegue evolución
Figura 4.3: Ciclo de vida e-Business.
El capítulo se organiza a continuación presentando estas cuatro etapas.

EJ EMPLO DE PROY ECTO TECNOLÓ GICO: IM PLANTACIÓN PROYECTO E-B USI NESS
FUNIBERff
Para llegar a ser una empresa e-Business y ofrecer un mejor se rvic io al cliente , la
empresa debe ante todo desarrollar una estrategia a largo plazo para la integración de
sus procesos. Más del 55 % de empresas (todas con soluciones e-Business ya
implantadas) reconocen que inicialmente só lo pensaron en necesidades aislada s y a
corto plazo, sin definir sus objetivos e-Business a largo plazo , ni desarro l lar una
verdadera estrategia e-Business.
Las empresas que elabo ran este tip o de estrategia posteriormente , durante la fase de
desarrollo y despl iegue , señalaron que sus soluciones iniciales probablemente hubiesen
sido otras, o impl antadas de otra m an era, si hubiera existido una visión e-Business. Sin
un plan claramente definido a largo plazo, estas soluciones puntuales, a pesar de
r esu ltar exitosas indivi dualmente, en conjunto co nstitu ye ron una serie de iniciati vas
costosas y desarticuladas qu e obstac ul iza ron la integració n total y racional de los
procesos empresariales. En general es la escasa rentabilidad de la inversión lo que causa
mayor frustrac ión. En estos casos , después de implantar va rias so luciones parc ia les y
poco optimizadas, las empresas se ven forzadas a defin ir una estrategia con el objetivo
de articular sus dispare s pro gra mas e -Business sobre un eje co mún: la mejora del
<
se rv ic io al cliente . "':::
"'"'
>
Por el contrario, empresas que desde el principio apoya n la implantación en un
verdadero proyecto a largo plazo , se benefician de una ven t aja significativa a la ho ra de z
o
ü
<
ofrecer un mejor serv icio a sus clientes, con resulta do más sati sf actorio en la inversión ~
:::>
en e-Business. En el 42 % de estas em presas , la inversión en e-Business resulta muy u..
positiva o ha cambiado radicalment e la fisionomía de su negocio (un porcentaje más de

dos veces superior al de las empresas sin estrategia a largo plazo) , y ninguna se muestra
insatisfecha c on los resultados de sus proyectos e-Business.
Esta diferencia se expl ica principa lmente po r el he cho de que las so luciones e-Business
que optimi zan procesos o sistemas individuale s -sin t ene r en cue nta el entorno global-
sólo conducen a mejoras puntuales. En cambio, un plan e -Business que abarque la
totalidad de lo s procesos aportará resultados sig nif icativos en términos de valor
añadido , tanto para la empr esa como pa ra sus clientes , colabo rado res y proveedores,
ofreciendo ventajas signifi ca t iv as en el plano de la competitividad y de la satisfacción
del clien t e.
Formular l a est rat eg ia de n egoc ios para el uso ef ectivo de la so lución e -Business
debe ría:
• Definir la misión p ara el uso de la sol ución e-Business.
• Establecer obj etivos alineados con la misión y con los objetivos corporativos .
198 D IRECC I Ó N Y GESTIÓ N DE PROYECTOS TIC

EJ EMPLO DE PROYECTO TECNOLÓGICO: IMPLANT ACIÓN PROY ECTO E-B USINESS
• Diseñar un a est rategia que ayud e a la organización a lograr sus objetivos.
• Identificar cómo la estrategia será implantada dentro de la transformación de

procesos de negocio.
T odo esto da luga r al documento estratégico, procu rando mostrar un alto nivel de
det al le y complet itud en varios aspect os (po r ejem plo , ver Apéndice 1).
4.2.1 DEFINIR LA MISIÓN
El é x ito en el mercado o nl i ne requiere una comprens1on deta ll ada de cóm o la

organización planea usa r In t ernet. Aunque est o pueda son ar trivial , frecuentem ente el
producto a ser ofr ecido en la red requiere un dominio de l espacio donde se ha de ofrecer
y donde se ha de negociar.
Esto hace dificultoso determ inar cómo el producto es pos ic ionado en el merc ado y
<
z
<
u cómo la organización puede medir el éxito en su esfuerzo en la red .
~
z
<
o
Por ejemplo , muchas organizacione s u san el método A BC (Activity Based Casting) p ara
..
~
localizar costos en departament os individuales. La técnica tradicional de implantación
de ABC no trabaja en una Economía en Red porque la o rganización gasta gran cantidad
de recursos construyendo productos y servicios que son dejados gratis en la red. Para
comp r ender este concepto , podemos tene r en mente compañías como Yahoo o
lnfoseek, las cuales proveen moto res de búsqueda .
El servicio / producto ofrecido po r Yahoo e lnfoseek es la capacidad de b u scar

información en la web. Millones de clientes acceden a sus sit ios (web sites) diariamente
y de manera gratuita . Nue v os serv icios tales como Gesto res de Portafolio Persona l
(Personal Po rtfo/io Man agers ) y capa c id ad e s de búsqu ed a p ersona l izad as es t án
disponibles en estos sitios .
Así, an t e la pr egu n ta ¿cómo su bsi ste n estos n egocios? , la respuesta es s i mple : el

principal flujo de retorno o ganancia para estas compañías proviene de av isadores qu e
desean pub licita r sus productos y se rv ic ios , y de organ izaciones que desean conduc ir
tráfico a sus sitios y no de cl ientes que usan los motores de búsqueda .
Por tanto , el producto que ofrece concretamente Yahoo e lnfosee k es el ac c eso a

millo nes de clientes que dese an usar un motor de búsqueda , donde el éxito en el medio
ambiente que provee el sitio a través de sus páginas w eb está med ido en la capacidad
de atraer gente al sitio a usar el moto r de búsqueda y que vuelva de nuev o .
DIRECCIÓN Y GESTIÓN DE PROYECTOS TJC 19 9

E JEMPLO D E PROYE CTO TECNOLÓGICO : I M PLA NTACIÓN PROYECTO E-B US I NESS
FUNIBERfj
Un caso análogo lo constituye la televisión. En este caso, buena parte de sus ingresos y
ganancias provienen de la cal idad de sus contenidos , los cuales atraen a entidades
interesadas en hacer publ icidad.
Debe recalcarse que esto no significa que una iniciativa e-Business equivale a solamente
publicar información de la empresa. Por ejemplo, no es sólo crear una página web para
consulta general, poner una int r anet para los empleados, o una extranet para sus
colaboradores.
Lo que importa es construir una comunicación bidireccional: cuando se integran web ,

extranet o intranet con los sistemas existentes en la empresa, se crean nuevas
oportunidades para que los clientes , empleados , proveedores y distribuidores
interactúen en cualquier momento y en cualquier lug ar. De esta forma , la comunicación
se hace más eficiente. En lugar de trabajar a través de intermediarios, las principales
partes implicadas obtendrán la información que necesitan directamente y podrán realizar
sus transacciones con la empresa de forma electrónica.
De esta manera, conforme los empleados, proveedores , distribuidores y los clientes <
z
<
:!
disponen de mayor acceso a los datos y son capaces de interactuar directamente con ~
::¡:
<
los sistemas centrales de la empresa , éstas descubren nuevas posibilidades sobre cómo o
utilizar sus recursos. De hecho , los datos que se producen como resultado de una .."'
w
<
~
interacción más directa con las principales partes implicadas son en sí mismas un ...<
recurso . Permiten aprovechar la experiencia y el conocimiento de la institución para "'"'
~
>
llevar a cabo un cambio fundamental en la forma de conducir la empresa . Esto es lo z
:::>
z
realmente importante de e-Business . Paradójicamente , los cambios en los aspectos '0
u
<
tecnológicos de una empresa pueden llevar a modificar en última instancia los procesos o
z
::>
"-
centrales de la empresa , aspectos de una empresa que no tienen nada que ver con la ~1
tecnología.
4.2.2 ESTABLECER OBJETIVOS
Las empresas consideran que existen numerosos obstáculos que pueden frenar la
implantación inicial y la ampliación de sus proyectos e-Business. El principal obstáculo
para una mayor inversión en e -Business es el alto coste de implantac ión (coste real y
recursos internos necesarios) . Sin embargo, la idea de que el e -Business " es
exce siva mente oneroso y exige un gran número de re c urs os " h a sido totalmente
desment ida por la mayor parte de las empresas que han atra v es ado con éxito la
"terrible" fase inicial.
Las empresas que han realizando su proyecto e -Business basándose en una sólida
estrateg ia , y han perse v erad o el tiempo suficiente para cosechar sus frutos , se
m arav ill an del bajo coste de di ch as soluciones con re specto a los ben efi c ios que pueden
200 D IRECCIÓN Y GESTION DE PROYECTOS TI C

EJ EMPLO DE PROYECTO TECNOLÓGICO: 1M PLANTACIÓ N PROYECTO E-B USINESS
FUNIBER fj
------------------------------------
aportar. El análisis de la rentabilidad de la inversión es sólo uno de los componentes de
la ecuación del valo r del e-Business. Existen otros factores, de t ipo cualitativo, que se
deben tener en cuenta: estabilidad de las nuevas relaciones que se establecen con los
clientes, eficacia óptima de los empleados, mayor fidelidad de los proveedores,
aumento potencial del volumen de ingresos gracias a la optimización de los procesos,
sin olvidar la ventaja competitiva proporcionada por la mayor rapidez de reacción de la
emp resa.
Un análisis detallado y riguroso de los beneficios estratégicos y comerciales resulta

indispensable para vence r los obstáculos que impiden la adopción e implantación del
e-Business. De hecho, más allá de los aspectos puramente tecnológicos , los obstáculos
principales desaparecerán ante la total comprensión del valor operativo y de los
considerables beneficios financieros inherentes a la transición hacia el e-Business.
Por este motivo es conveniente hacer una definición de objetivos claros , concisos y,
muy importante, medibles del tipo estratégico y financiero.
<
z
<
~
~ a.1. - Objetivos est ratégicos
<
o
::¡
"' Estos objetivos tiene que ver con, primero, cómo la organización busca ser reconocida
"<
~
en el mercado y, segundo, con respecto a su competencia.
¡;¡
~
>
::> Por ejemplo , pueden señalarse como objetivos estratégicos:
.25
'-'
<
o Ser un reconocido líder del mercado.
5
u.
Incrementar posición en el mercado.
Proveer un mejor servicio al cliente.
Tener una estructura de costos más baja que la competencia.
Tener una alta capacidad de respuesta frente a los cambios del mercado.
Ofrecer productos de alta y reconocida calidad.
Caso: e -Businessvale la pena. Y mucho
En un estudio llevado a cabo por The McKenna Group (empresa consultora de Silicon Valley) e IBM, se
examinaba la importancia de e-Business en empresas de fabricación, de ventas al por menor, aseguradoras,
de telecomunicaciones y de viajes. En cada uno de estos sectores, se encontró un va lor significativo tanto en
términos de crecimiento de los ingresos como en ahorro de costes.
e-Business crea oportunidades significativas para aumentar los ingresos y mejorar la satisfacción de los
clientes. En el estudio se encontraron numerosos ejemplos de empresas que experimentaron un crecimiento
de los beneficios de dos e incluso tres dígitos a partir del momento en que rea lizaron la transición al entorno
e-Business.
Estas empresas consideran que e-Business les ha permitido captar nuevos clientes y ofrecer un mejor servicio
a los clientes habituales.

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-B USINESS
FUNIBER
b . 1 .- Objetivos financieros
Estos objetivos identifican los re sultados financieros que la organización esta buscando
alcanzar con el esfuerzo en e-Business.
Por ejemplo, pueden señalarse como objetivos financieros:
In crementar los márgenes de ganancia.
Contribuir a acelerar el crecimiento de los ingresos.
Reducir gastos aumentando la eficiencia de los procesos de negocio.
Caso: Las soluciones e-Business también permiten recortar costes
La dirección de una empresa de componentes electrónicos diversificado que ha puesto en marcha un extranet
segura para comunicarse con los proveedores de suministros no relacionados con la producción reconoció que
estaban derrochando millones de dólares en compras colectivas porque dichas compras se dispersaban entre
las distintas divisiones de la empresa. Debido a que la adquisición de los productos no relacionados con
producción no estaba estandarizada, la empresa no podía seguir la pista de las múltiples transacciones que <
z
podían constituir una única compra ni analizar el historial de compras para poder mejorar. :
<
La empresa eligió una solución extranet basada en la Web conectada a los sistemas ya existentes. De este o
"'
modo, se obtiene un acceso estandarizado para todos los suministradores, un medio para conectar los "'"'
diversos sistemas de aprovisionamiento de cada división y se evita la utilización de redes de interconexión
dedicada, más caras, para la transmisión de datos.
¿El resultado? El fabricante estima, siendo conservador, que los costes anuales en las transacciones de
aprovisionamiento se reducirán en un 75%, y que ahorrarán 60 millones de dólares al año al consolidar su
poder adquisitivo con los proveedores habituales.
4.2.3 DISEÑAR UNA ESTRATEGIA
Una estrategia de negocios puede ser definida como los movimientos e intentos de una
organización para producir un desempeño exitoso acorde al negocio. Es destacable que
el aspecto central de l a estrategia de negocios es cómo cons tru i r una posición
competitiva de largo plazo. Por último, puede decirse, que la estrategia de negocios es
poderosa si ella produce una ventaja competitiva considerable y, además, sostenible.
Las empresas que ya trabajan en el entorno e-Business con éxito, tienden a ver el
cambio como una oportunidad y no como un desafío. Esto es importante porque las
soluciones e-Business se desarrollan en entornos cambiantes . La tecnología evoluciona
a un ritmo rápido. Las normas de la competitividad están cambiando. El poder relativo y
la influencia de los clientes, proveedores y distribuidores está cambiando en todos los
sectores. Los clientes también tienen una visión diferente de la capacidad de respuesta
que puede ostentar una empresa hoy por hoy ; la tecnología digital , el mundo
202 DIRECCIÓN Y GESTIÓN DE PROYECTOS T!C

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTAC IÓN PROYECTO E-BUS INESS
FUNIBER
int erconectado en que vivimos hace que esperemos una respuesta inmediat a y que los
servicios se encu entren disp onibles las 2 4 ho ras.
Consideraciones estratégicas
Como parte de la estrategia es conveniente analizar determinados aspectos que pueden considerarse
estratégicos, tanto de negocios como tecnológicos. Estos aspectos son:
• Ofrecer un contenido en la red de buena calidad, de tal manera que un "click'' en nuestra página invite a
ser visitada nuevamente.
• El diseño gráfico debe ser atractivo, buscando una armonía entre lo visual y el texto, entre color, imagen
y dinámica.
• La comunicación que ofrezca el sitio web debe ser eficaz. Esto quiere decir, que se deben entregar
mensajes claros para el mercado escogido, en su propio lenguaje y con sus propios signos.
• La interacción debe ser fluida. Esto significa que el usuario debe tener a su disposición herramientas que
le permitan seleccionar información y navegar por el sitio según sus necesidades.
• La navegación debe ser lógica. Hay que pensar en el usuario, en el tipo de cliente escogido, para
ofrecerle un tipo de navegación que le resulta familiar con sus estilos habituales de trabajo, de
conversación, de uso de I nternet.
z< • La programación computacional debe prevenir errores. Sencillamente que la página o las páginas del sitio
<
u funcionen sin errores, sin sobresaltos, sin pérdida de información.
I!"'< • Actual ización frecuente. Una página web no es un documento en el olvido, es nuestro rostro, el cual debe
o
continuamente ser cuidado con mucha atención para ofrecer una imagen y un contenido adecuado.
~
• La promoción de nuestro sitio web debe ser continuo y real. El sitio web es nuestra personal y privada
invenoón, por lo tanto, debemos avisar que ella existe. Notas de prensa, publicidad, presencia en medios,
"'
~
indexaciones en buscadores, son medios para mostrar su existencia, anunciar cambios, nuevos productos
>
z y promociones, etc.
::>
z • Mantener la fidelidad. Fidelizar no es solamente capturar datos, sino informar sobre novedades, nuevas
-~
u
< promociones, etc., por este motivo debemos construir un vínculo personal con el usuario afiliado a
e
z nuestro negocio.
...
::>
<"' ** BURGOS, DANIEL. (2001). Claves para aumentar el tráfico de un si te. e.sphera. 4:16. Mayo.
"'
Para conseg uir una estrategia de negocios adecuada , se deben considera r los siguientes
aspectos:
• Coherencia con el negocio principal.
• Análisis de fue rzas externas.
• Análisis de mercado.
a. 1.- Coherencia con el negocio principal
Para ap rovechar el potencial de las soluciones e-Business , es imperativo para una

organización establecer clara y consistentemente una estrategia de negocios alineada
con la estrategia corporativa de la empresa y, además, tomando en consideración los
obje t ivos de negocios qu e han sido de f inidos pr ev i ame n te. Una g ran parte de la
estrategia de negocios consiste en identificar cómo la organización desea competir en el
mercado.

EJEMP LO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-BUSINESS
FUNIBER
Este enfoque puede hallarse basado en los siguientes criterios:
Competir basado en la calidad . Ser reconocido por la calidad de los productos.
Tiempo de respuesta al mercado. Ser rápidament e reconocido como un

innovador.
Mejor servicio. Provee r el mejor se rvicio al clie nte.
Costes bajos. Ser reconocido como el proveedor de cost o más bajo .
Mejor seguimiento del servicio provisto. Ser reconocido por la calidad y

completitud de la gestión del seguimiento.
CASO : VINOS GANCIA
Con una plantilla de 150 trabajadores y unos ingresos de 70 millones de dólares al año, Gancia
(www. ganc1a .. t ) tiene mucho en común con otras empresas italianas que han alcanzado el éxito: sus raíces
son locales, pero su mercado es global. Fundada en 1850 en las montañas piamontesas del norte de Italia, la
empresa exporta sus vinos a cerca de 60 países de todo el mundo. <
z
<
u
El éxito de Gancia siempre se ha basado en una esmerada mezcla entre tecnología y tradición, y comprendió 8
~
casi de inmediato los beneficios que una solución e-Business podía aportar. Gancia necesitaba una solución de ~
TI que le ayudara a hacer más eficientes las operaciones del mercado doméstico y le diese el soporte "'
<
necesario para gestionar el creciente mercado internacional, un área de importancia estratégica para la
"<
empresa. Así lo cuenta el gerente de Gancia: "Somos una de las primeras marcas de Italia, pero el futuro de
la compañía es el mercado global. Por ello necesitamos un mejor acceso al mercado internacional".
Los especialistas en e-Business analizaron detenidamente el flujo de información a través de las cadenas
empresariales de la compañía y su probable evolución en el futuro. La primera solución propuesta fue la
creación de una solución preparada para el año 2000 para las necesidades de contabilidad básica y de gestión
de Gancia.
Previamente, los pedidos que llegaban a la oficina de ventas de la empresa por fax generaban una gran
cantidad de papel que requería la dedicación exclusiva de varios empleados. Estos pedidos llegaban sin un
formato estándar, lo que obligaba a interpretarlos y, a menudo, descifrarlos se convertía en un juego de
adivinanzas. Nuestro socio informático ABC diseñó una pagina web que permite a los agentes presentar sus
pedidos rellenando un simple formulario. El enlace con Internet se ofrece a través de un servidor Lotus
Domino, que se encuentra enlazado con Internet con el sistema de contabilidad y gestión de la empresa, que
funciona en un servidor AS/ 400.
Además de la red de agentes, Gancia necesitaba un enlace con 7 almacenes de depósito repartidos por toda
Italia desde donde se distribuye a los clientes. Anteriormente, la comunicación con estos almacenes generaba
un intenso intercambio de papeleo, un flujo constante para arriba y debajo de notas de entrega, pedidos e
información sobre facturas. Gran parte de los documentos se enviaban por fax, creando aún más trabajo
administrativo y mayor probabilidad de retrasos. Para tratar este problema, se creó una solución Lotus Notes
que enlazaba los almacenes con las oficinas centra les de Gancia mediante una extranet. Los datos de entrega
de los almacenes se pasan automáticamente al sistema de contabilidad central de Gancia, de manera que se
puede emitir la factura correcta.

EJEMPLO DE PROY ECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-BUSINESS
FUNIBER
La solución reduce el tiempo de dedicación a la gestión administrativa de los pedidos recibidos por fax y
reduce drásticamente los problemas generados por errores o pérdidas de los documentos. La plantilla de
Gancia que antes se encargaba de atender el fax, ahora sólo dedica un 10% de su tiempo en el control del
sistema y el resto lo pueden dedicar a otros trabajos más productivos para la empresa. Otra ventaja de recibir
los pedidos en línea es que los datos de ventas están siempre disponibles para su análisis. De esta forma,
Gancia puede controlar las tendencias de ventas por área y producto utilizando datos del momento.
Los agentes y los almacenes de depósitos de Gancia también se benefician del descenso de las tareas
administrativas. Al mismo t iempo que el trabajo de los agentes y de los almacenes es más efectivo, se
consolidan las relaciones entre ellos y la empresa, lo que constituye una parte importante de los activos de
Gancia.
Actualmente, el sistema se utiliza para los pedidos que se cursan en Italia, pero Gancia pronto lo abrirá a los
agentes internacionales de 60 países. Mediante interfaces de usuario personalizadas, se salva el gran abanico
de diferencias cultu rales y problemas de comunicación. Por ejemplo, un importador j aponés podrá colocar sus
pedidos utilizando un formulario que esté en su idioma, Butterworth dice: "Hemos crecido dos dígitos en
Japón. Se trata de un país con otra lengua, otra zona horaria y otra cultura. Necesitamos la tecnología para
resolver nuestros problemas de comunicación y mantener dicho mercado en crecimiento".
<
b. 1 .- Análisis de fuerzas externas
z
<
V
e;
Un segundo aspecto de la estr ategia de negocios identifica las fuerzas externas que
"<
o
~ impactan la organización. Las f uerzas que pueden destaca rse son:
<
;;;
<
Competencia.
"'
e;
>
z
:::;¡ Potenciales nuevos proveedo res.
z
o
ü
e< Regulaciones de gobierno.
5
u.
Implicaciones culturales.
Estas fuerzas su r gen del enfoque pa r a la planificación de la est r ategia corporativa

propuesto en 1980 por Michael E. Porter en su libro "Competitive Strategy: Techniques
far Analyzing Industries and Competitors".
El punto de vista de Po r te r es que ex i sten cinco fuerzas que determinan las

consecuencias de rentabilidad a largo plazo de un mercado o de algún segmento de
éste. La idea es que la corporación debe evaluar sus objetivos y recursos frente a éstas
cinco fuerzas que rigen la competencia de un sector. Además Porter consideró una se rie
de barreras que dificultan la entrada de una empresa a un determ inado sector.

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLAN TAC IÓN PROYEC-0 E-BUSINESS
FUERZAS:
Amenaza de entrada de nuevos competidores. Falta de atractivo si las barreras de entrada son fáciles
o no de franquear por nuevos participantes que puedan llegar con nuevos recursos y capacidades para
apoderarse de una porción del mercado. Por ejemplo, el uso masivo y barato de web-hosting por parte de
competidores.
La rivalidad entre los competidores. Problemas de competencia si en un mercado o en uno de sus

segmentos los competidores estén muy bien posicionados, sean muy numerosos y los costos fijos sean altos,
pues existe alto riesgo de guerra de precios, campañas publicitarias agresivas, promociones y entrada de
nuevos productos. Por ejemplo, competir hoy en día en venta de libros on-line.
Poder de negociación de los proveedores. Un mercado o segmento del mercado no será atractivo
cuando los proveedores estén muy bien organizados gremialmente, tengan fuertes recursos y puedan
imponer sus condiciones de precio y tamaño del pedido. La situación será aún más complicada si los insumos
que suministran son claves para nosotros, no t ienen sustitutos o son pocos y de alto costo. Por ejemplo, el
coste del uso de telecomunicaciones fijado por empresas de telefonía.
Poder de negociación de Jos compradores. Poder de clientes bien organizados, en cuyo caso el
producto tiene varios o muchos sustitutos, el producto no es muy diferenciado o es de bajo costo para el <
z
<
cliente, lo que permite que pueda hacer sustituciones por igual o a muy bajo costo. Por ejemplo, exigencia u
;;¡
actual de tener una canasta de compra flexible y rápida. ~
<
o
Amenaza de ingreso de productos sustitutos. Un mercado o segmento no es atractivo si existen
productos sustitutos reales o potenciales. La situación se complica si los sustitutos están más avanzados
tecnológicamente o pueden entrar a precios más bajos reduciendo Jos márgenes de utilidad de Ja corporación
*
<
¡;:
~
¡;;
y de la industria. Por ejemplo, las alternativas a la venta on-/ine, como lo es el uso del fax. "'?:
w
z
=>
z
·O
ü
<
o
z
:::>
....
Competencia!
Amenaza
potencial
Poder negociador Poder negociador
Competidores en la industria
Proveedores rivalidad entre ellos Compradores
Sustitutos Amenaza
Figura 4.4: Modelo de cinco fuerzas de Porter.

EJEMPLO OE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-BUSINESS
Economías de Escala. Supone al que las posea, debido a que sus altos volúmenes le permiten reducir sus
costos, dificultar a un nuevo competidor entrar con precios bajos. Por ejemplo, la caída de las barreras
geográficas y la reducción del ciclo de vida de los productos, obliga y hace vulnerable un negocio a
competidores más ágiles que operan globalmente.
Diferenciación del Producto. Asume que si la corporación diferencia y pos1c1ona fuertemente su

producto, la compañía entrante debe hacer cuantiosas inversiones para reposicionar a su rival. Por ejemplo, el
riesgo en la facilidad de copia de una página web, donde un mínimo cambio hacia una mejor presentación es
difícil de demostrar.
Inversiones de Capital. La idea es que aquellos con fuertes recursos financieros tendrán una mejor
posición competitiva frente a competidores más pequeños, le permitirá sobrevivir más tiempo que éstos en
una guerra de desgaste, invertir en activos que otras compañías no pueden hacer, tener un alcance global o
ampliar el mercado nacional e influir sobre el poder político de los países o regiones donde operan.
Desventaja en Costos independientemente de la Escala. Sería el caso cuando compañías

establecidas en el mercado tienen ventajas en costos que no pueden ser emuladas por competidores
potenciales independientemente de cual sea su tamaño y sus economías de escala. Esas ventajas podían ser
las patentes, el control sobre f uentes de materias primas, la localización geográfica, los subsidios del
< gobierno, su curva de experiencia, su conocimiento o acceso a información privilegiada.
"'u
<
5 Acceso a los Canales de Distribución. En la medida que los canales de distribución para un producto
>:
<
o estén bien atendidos por las firmas establecidas, los nuevos competidores deben convencer a los
~ distribuidores que acepten sus productos mediante reducción de precios y aumento de márgenes de utilidad
para el canal, compartir costos de promoción del distribuidor, comprometerse en mayores esfuerzos
promocionales en el punto de venta, etc, lo que reducirá las utilidades de la compañía entrante. En el caso de
e-Business, el canal de distribución tiene un bajo coste, no obstante construirlo con los clientes es el
problema.
Política Gubernamental. Las políticas gubernamentales pueden limitar o hasta impedir la entrada de
nuevos competidores expidiendo leyes, normas y requisitos. Los gobiernos fijan, por ejemplo, normas sobre
el control del medio ambiente o sobre los requisitos de calidad y seguridad de los productos que exigen
grandes inversiones de capital o de sofisticación tecnológica y que además alertan a las compañías existentes
sobre la llegada o las intenciones de potenciales contrincantes. Hoy la tendencia es a la desregularización, a
la eliminación de subsidios y de barreras arancelarias, a concertar con los influyentes grupos de interés
político y económico supranacionales y en general a navegar en un mismo océano económico donde los
mercados financieros y los productos están cada vez más entrelazados.
c . 1 .- Análisis de mercado
Finalmente, para comp leta r la est rategia, la organización debería defini r su mercado
objetivo . Esto incluye identificar clientes potenciales y determinar si el prod u cto será
ofrecido en el mercado a un amplio rango de clien tes u ofrecido a un nicho específico de
mercado.
Esto también incluye definir cómo la organización planea representarse a sí misma en la

Red o, en otras pa labras, cómo promover la organización y el producto o servicio a sus
cl ientes.
DIRECCIÓN Y GESTIÓN OE PROYECTOS T IC 2 07

E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACI ÓN PROYECTO E-B US I NESS
FUNIBER
Un análisis de mercado en un proyecto e-Business requiere estudiar la demografía de la Web del mercado o
segmento a abarcar. Esto permite tener una visión del mercado potencial de usuarios conectados. A modo de
ejemplo puede mostrarse que la población conectada crece continuamente, igualmente el número de
servidores web, conformando todo esto una masa crítica innegable.
Internet Users in the World

D istribution by World Regions - 2011
Asia 44.0'%
Europe 22.7%
North Amenca 13.0%
Lat Am/ Caribb 10.30/o
Africa 5.7%
M1ddle East 3.3%
Oceania/ Australia 1.0%
<
z

z
::>
Chrome 16.0 z
·O
ü
<
IE 8.0 o
z
,f
Firefox 8.0
IE 9.0
F1refox 3.6
Firefox 9.0
I E 7.0
IE 6.0
Firefox 7.0
Firefox 6.0
F1refox 4.0
Chrome 15.0
Other
0% 8% 16% 24% 32% 40%
Figura 4.6: Análisis de mercado. Datos sobre versiones de browseren Latinoamérica 2.
l. InternetWorldStats. Enlace web: ttto· w1\,v nterne¡ \Orlds;a:s co~lct2¡c; "i"'
208 DI RECCIÓN Y GESTI ÓN DE PR OY ECT OS TIC

E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-BUSI NESS
4.2.4 TRANSFORMACIÓN DE LOS PROCESOS DE NEGOCIO
En el mundo de la interconexión, el trabajo se puede realizar mediante varias líneas de

comunicación, so rteando distintas fronteras y jerarquías. Al utiliza r las tecnologías que
ofrece Internet p ara transforma r los procesos de la emp resa, también se modifican las
relaciones que se tenían con los c lientes, empleados, proveedores o distrib uidores .
• Clientes . El entorno e-Business permite pasar del marketing de masas a la

personalización en masa, dirigida a clientes individuales. También ayuda a
establecer relaciones a largo plazo con los clientes que tienen tipos de negocios
que se repiten durante toda la vida. A su vez , el entorno e-Business permite
trasladar las funciones del proceso de transacción hasta el despacho del cliente,
con la consiguiente reducción de costes, ciclos más corto s y mayor fidelidad del
cliente.
• Empleados . e-Business ayuda a que cada uno de los empleados esté tan preparado
como el que más. Permite que los empleados dispongan de la información que
<
z necesitan cuando la necesitan. Ayuda a maximizar la comunicación entre
<
~ colaboradores y ofrece un mundo de información disponible para toda la empresa.
~
>:
<
o
• Proveedores/Distribuidores . e-Business refuerza las asociaciones a través de la
..::¡ cadena de suministros y permite interactuar con los proveedo res de un modo que
:!:
a:
<
Vi
era impensable hace sólo unos pocos años . Permite a la empresa trabajar más
~ estrechamente con sus proveedores gracias a la extensión de los sistemas a través
>
z
::> de Internet y a la creación de aplicaciones que hacen más eficiente la cadena de
·~
ü
<
suministros ahorrando tiempo y dinero .
Q
z
"
u..
'"'
3 historias, 3 ejemplos
• Un centro hospitalario americano ha implantado un sistema basado en la Red a fin de poder recuperar a
distancia los expedientes clínicos destinados a un servicio de urgencias. Esto le permite un ahorro anual
superior a 1 millón de dólares y un posible aumento en los ingresos de 3 ó incluso 4 millones de dólares,
debido a una mayor fidelidad de los pacientes y a un aumento del número de médicos afiliados gracias a
la excelente reputación conseguida ...
• Un fabricante alemán de cables industriales instala en la Red un sistema de pedidos para sus clientes,
integrándolo con sus sistemas de abastecimiento, gestión de Inventarios y fabricación. Esto agiliza en un
75% la rotación de los pedidos y reduce en más de 500.000 dólares los costos administrativos anuales ...
• Un banco de cobertura nacional americano de gran envergadura establece en la Red una solución que
permite a sus 16 millones de clientes presentar y pagar sus facturas. Recientes resultados, indican que la
probabilidad de que los clientes cambien de banco es cinco veces menor, los saldos de sus cuentas son
tres veces mayores y su rentabilidad es 2,6 veces superior en un cliente promedio que utiliza servicios
bancarios online ...
2. BAEZA, !TALO. ( 2012). Ya es seguro crear sitios para navegadores post-2009 en Latinoamérica. En CHW. Enero, 4.
Enlace web: tittp: . 1; ·' "• .ch1·• net. 20l:: 101 ya-e~ - c;egvo - crear-s - os-:Jara -raveoac • s-post-2009-en-19; no2rno;,r e;:
D I RECCIÓN Y GESTIÓN DE PROYECTOS TIC 20 9

EJEMPLO D E PROYECTO TECNO LÓGICO: IMPLANTACIÓN PROYECTO E-B USIN ESS
FUNIBER
En función del secto r , existen d i stintos proceso s de la emp r esa que pueden se r
considerados como los más importantes y que influyen directamente en una mayor
recuperación de la inversión a lo largo de la transacción de una empresa tradicional a e-
Business. En la banca , por ejemplo , los sistemas de soporte al cliente son importantes,
así como el pago puntual y los cobros de las facturas. En la distribución al por menor,
por otro lado , las mejoras eficaces en la adquisición de clientes , el aprovisionamiento y
los sistemas de gestión de las existencias proporcionan la mejor recuperación de la
inversión.
Sin embargo, prácticamente todos los sectores afrontan un conjunto de retos comunes.
Y aunque los términos pueden ser distintos de sector a sector , los 3 procesos cla v es
que proporcionan la mayor recuperación de la inversión en un entorno e-Business son:
• Gestión de las relaciones con el cliente.
• Gestión de la Cadena de Suministros .

<
• Comercio electrónico. z
<
~
::
"'
<
a.- Gestión de las relaciones con el cliente (CRM: Customer Relationship o
Management)
..
::
<
«
;:
¡¡;
Asegurarse de que los clientes estén satisfechos, ofrecerles aquello que desean y en el e:>
z
momento que lo desean. Este proceso es la transformación de pasar del cliente puntual ::>
z
al cliente de por vida. ~
u
<
o
z
::>
u.
CRM es básicamente la respuesta de la tecnología a la creciente necesidad de las o
empresas de fortalecer las relaciones con sus clientes.
Las herramientas de gestión de relaciones con los clientes (Customer Relationship

Management CRM) son las soluciones tecnológicas para conseguir desarrollar la "teoría "
del marketing relacional. El marketing relacional se puede definir como "la estrategia de
negocio centrada en anticipar, conocer y satisfacer las necesidades y los deseos
presentes y previsib les de los clientes".
Actualmente , gran cantidad de empresas están desarrollando este tipo de 1nic1ativas .

Según un estudio realizado por Cap Gemini Ernst & Young de nov iembre del año 2001 ,
el 67 % de las empresas europeas ha puesto en marcha una iniciativa de gestión de
clientes (CRM).
En el proceso de remodelación de las empresas para adaptarse a las necesidades del

c liente, es cuando se detecta la necesidad de replantear los conceptos "trad icionale s"
del marketing y emplear los conceptos del marketing relacional:

FUNIBER~
EJE MPLO DE PROYE CTO TE CNOLÓG I CO: I MPLAN TAC I Ó N PROY ECT O E-B USI NE SS
-------------------------------------
• Enfoque al cliente: "el cliente es el rey". Este es el concepto sobre el que gira el
resto de la "filosofía" del marketing relacional. Se ha dejado de estar en una
economía en la que el centro era el producto para pasar a una economía centrada
en el cliente.
• Inteligencia de clientes : Se necesita tener conocimiento sobre el cliente para poder

desarrolla r productos /servicios enfocados a sus expectativas. Para convertir los
datos en conocimiento se emplean bases de datos y regl as.
• lnteractividad: El proceso de comunicación pasa de un monólogo (de la empresa al

cliente) a un d iálogo (entre la empresa y el cliente). Además, es el cliente el que
dirige el diálogo y decide cuando empieza y cuando acaba.
• Fidelización de clientes: Es mucho mejor y más rentable (del orden de seis veces
menor) fidelizar a los clientes que adquirir clientes nuevos. La fidelización de los
clientes pasa a ser muy importante y por tanto la gestión del ciclo de vida del
cliente.
z<
• El eje de la comunicación es el marketing directo enfocado a clientes individuales
<
~ en lugar de en medios "masivos" (TV, prensa, etc.) . Se pasa a desarrollar
~
z<
o campañas basadas en perfiles con produc t os, ofertas y mensajes dirigidos
~
"' específicamente a ciertos tipos de clientes, en lugar de emplear medios masivos
::o:
< con mensajes n o diferenciados.
"':::
~
z • Personalización : Cada cliente quiere comunicaciones y ofertas personalizadas por lo
:::>
z que se necesitan grandes esfuerzos en inteligencia y segmentación de clientes. La
'°ü<
o
z
personalización del mensaje, en fondo y en forma , aumenta drásticamente la
:>
u.
eficacia de las acciones de comunicación.
• Pensar en los clientes como un activo cuya rentabilidad muchas veces es en el

medio y largo plazo y no siempre en los ingresos a corto plazo. El cliente se
convierte en referencia para desarrollar estrategias de marketing dirigidas a
capturar su valor a lo largo del t iempo.
Realmente , el marketing rela cional es algo que se ha venido haciendo durante siglos. Si
no , piense en el tendero de la esquina. Cuando va a comp rar siempre le reconoce, le
saluda por su nombre y le aconseja (le hace ofertas personalizadas) en función de sus
últimas consultas y comp ras.
El reto actual es conseguir conocer a los clientes y actuar en consonancia cuando en

lugar de tener 50 clientes como tiene el tendero , se t ienen 1 .000 , 5 .000 , 50.000 o
500.000.000. Esta posibilidad la ofrece la tecnología. Hasta que no han existido las
soluc iones de CRM y las bases de datos, era inv iable conocer y personalizar mensajes a
50.000 clientes.
D IRECCIÓN Y GESTIÓN DE PROYE CTOS TIC 211

EJ EMP LO DE PROY ECTO TECNOLÓGICO: I MPLANT ACIÓ N PROYE CTO E-B USIN ESS
FUNIBER
Los objetivos del marketing rela cional y las soluciones CRM son:
• Incrementar las ventas tanto por incremento de ventas a clientes actuales como por
ventas cr uzadas.
• Maximizar la información del cliente.
• Identificar nuevas oportunidades de negocio.
• Mejora del servicio al cliente.
• Procesos optimizados y personalizados.
• Mejora de ofertas y reducción de costes.
• Identificar los clientes potenciales que mayor beneficio generen para la empresa.
• Fidelizar al cliente, aumentando las tasas de retención de clientes .
• Aumentar la cuota de gasto de los clientes.

<
z
<
En este contexto, es importante destacar que Internet, sin lugar a dudas, ha sido la u
5
:¡:
tecnología que más impacto ha tenido sobre el marketing relacional y las soluciones de <
o
CRM. A co ntinu ación, se desarrolla la contribución de Internet al marketing relacional: ~
<
;;:
<
• Impo rtante disminución de los costes de interacción. "'
::"'z
~
• Bidireccionalidad de la comunicación . ::>

z
·O
ü
<
• Mayor eficacia y eficiencia de las acciones de comunicación. o
z
::>
u.
Inteligencia de clientes. ~
Públicos muy segmentados.
- Personalización y marketing 1 to 1 .
• Capacidad de comunicar con cualquier sit io desde cualquier lugar.
• Mejora de la atención al cliente. Funcionamiento 24 hor as, 365 días.
• Mejora de los procesos comerciales.
Sin embargo , aunque la tecnología sea la herramienta para el desarrollo de la filosofía ,

nunca puede dejarse un proyecto CRM en manos de ella. Es muy importante destacar
que para alcanzar el éxito en este tipo de proyectos se han de tener en cuenta los
cuatro pilares básicos en una empresa: estrategia , personas, procesos y tecnología.
Estos conceptos se desarrollan a continuación:

f UN I BE R i~ • • • • •E•J•E•M•PL•o• o•E•P•Ro• Y•E•CliT•O•T•E•CN• O•L•ó•G•1c•o•:• 1•M•P•LA•N•T•Ac• 1•ó•N• P•R•o•v•EC•T•O• E•-•B•u•s I•N•E•s s•
• Est rategia : obviamente, la implantación de herramientas CRM debe estar alineado

con la estrategia corporativa y estar en consonancia de las necesidades tácticas y
operativas de la misma. El proceso correcto es que CRM sea la respuesta a los
requerim ientos de la estrategia en cuanto a la relaci ones con los clientes y nunca,
que se implante sin que sea demasiado coherente con ella.
• Personas : la implantación de la tecnología no es suficiente. Al final, los resultados

llegarán con el correcto uso que hagan de ella las personas. Se ha de gestionar el
cambio en la cultura de la o rgani zación buscando el total enfoque al cl iente por
parte de todos sus integr antes. En este campo , la tecnología es totalmente
secundaria y elementos como la cultura , la formac ión y la comunicación interna
son las herrami entas clave .
• Procesos: es necesaria la redefinición de los procesos pa ra opti m izar las relac ion es
con los clientes , consiguiendo procesos más eficientes y eficaces. Al fina l,
cualquier implantación de tecnolog ía redunda en los procesos de negocio ,
haciéndolos más rentables y flexibles .
<
z • Tecno log ía : también es impo rtante destacar hay soluciones CRM al alcance de
<
~
~
organizaciones de todos los tamaños y sectores aunque claramente la solución
:E:
<
o necesa ria en cada caso se rá diferente en función de sus necesidades y recursos.
o:
"''"
b.- Gestión de la cadena de suministros (SCM: Supply Chain Management)
Trabajar est rechamente con los proveedores para estar seguros de que tenemos
suficientes productos para vender. Facilitar a los proveedores la vis ión de las
aplicaciones internas de gestión de recursos de la empresa, puede que nos ayude a que
los proveedores se anticipen mejor a nuestras necesidades. Este proceso se encuent ra
·9
en la línea de reducc ión de costes, a la vez que también mejora la satisfacción del
cliente , ya que obtiene lo que desea y en el momento que lo precisa .
Debido a los avances en la fabricación y la distribución , está disminuyendo el coste del

desarrollo de nuevos productos y serv i c ios y se está acelerando el tiempo de
comercialización. Esto ha supuesto un aumento de las demandas de los clientes, de la
competencia local y global y de la presión en la cadena de suministros .
Para segu ir siendo competitivas las empresas deben reinventarse a sí mismas, de forma
que la cadena de suministros -abastecimiento y adqu is ición , planificación de
producción , cumplimiento de pedidos, gestión de inv entarios y atención al cliente- ya
no sea un ejercicio de trast ienda basado en los costes , sino una operación flexible
diseñada para enfrentarse de forma efe cti va a los desafíos actuales.
Internet está demostrando ser una herramienta eficaz en la transformación de las

cadenas de sum inistros de todas las industrias. Proveedores , distribu idores, fabricantes
y vendedores trabaj an ahora más estrecha y eficazmente que nunca . La cadena de
DIRECCIÓN Y GESTION DE PROYECTOS TIC 2 13

EJE MP LO DE PROY ECTO TECN OLÓ GI CO: I MPLANTACI ÓN PROYECTO E-B USI N ESS
FUNIBER
sumin istros actua l, controlada po r la tecnología, pe rmite a los clientes gestiona r sus
propias experiencias de compra, aumen t ar la coordinación y conectividad entre los
socios de suministro y ayudar a reducir los costes operativos de cada una de las
compañías de la cadena.
b. 1 .- Desafío
El incremento de las demandas de los clientes, la competencia y la subida de los costes

de desarrollo están cambiando la ca ra de los negoc ios en la economía de Internet. Las
empresas están intentando ahora reinventarse a sí mismas para satisfacer los plazos de
entrega cada vez más reducido s y satisfacer las cada vez mayores expectativas de los
clientes.
En el pasado, los activos eran un componen te crucial en el éxito de la gestión de la

cadena de suministros. En el mercado actual, sin embargo , una orientación centrada en
el cliente es clave para conservar la ventaja competitiva. Existen varios puntos que hay
que tener en cuenta a la hora de crear una cadena de suministros exitosa centrada en el <
z
<
~
cliente: ::;
"'o:
<
o
~
• Recibir pedidos es sólo una parte de atender las necesidades del cliente. Lo s "'
negocios deben cumplir la promesa que hacen a los clientes sumin istrando los
productos y la información bajo petición , y no cuando sea de inter és para la
empresa hacerlo.
• El t iempo de comercialización es una ventaja competitiva clave (Time to Market).

Las compañías deben garantizar un su ministro ininterrumpido y la info r mación
acerca de las demandas y actividades de los clientes es esencial para cumplir este
requerimiento .
• El coste es un factor importante . Las empresas necesitan reducir el coste de los

procesos internos para que los productos fina les sean menos caros .
• La reducción de los tiempos durante el ciclo de diseño es crítica ya que permite a

la s compañías difundi r sus productos más rápidamente para satisfa cer la demanda
de los clientes.
b. 2 .- Solución
El desarrollo e implementación de una cadena de sumin istros flexible y en red que

integ re a todos los socios - fabrica ntes , m in oristas, proveedores , transportistas y
vendedores- junto a una unidad sin fisuras es el primer paso para satisface r las
demandas actuales de los clientes y mantene r un perfil competitivo. El emprender este
paso es crucial para las compañías que buscan tomar mejores decisiones de estimación
en tiempo real , reducir su inventa ri o y los costes asociados y acelerar la entrega de

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-B USIN ESS
productos y servicios. Al hacerlo, las compañías t ransforman su cadena de suministros

desde un ejercicio de trastienda basado en los costes a una operación flexible diseñada
para enfrentarse de manera eficaz a los desafíos actuales.
La evolución de una cadena de suministros en red implica los siguientes pasos:
• Compartición de información estática o dinámica, incluyendo niveles de inventario,

planificaciones, previsiones y documentos de diseño , entre compañías y socios
mediante la integración de la Web con sistemas especializados como la
planificación de recursos empresariales (ERP).
• Realización de transacciones , incluyendo el intercambio de órdenes de pedido,

facturas, información de envío, etc. , a través de una red como Internet o una red
privada v irtual (VPN).
• Establecimiento de comunidades de negocio, como portales, mercados Web

financieros y comunidades de subastas y licitaciones, para permitir el desarrollo de
los negocios y la integración a las empresas.
<
z
<
u
3:t A través estos cambios , las empresas y sus asociados pueden verse a sí mismos como
<
o una única organización virtual. Los envíos se realizan bajo demanda y justo a tiempo, y
~
el ciclo de pago se simplifica. Como resultado, las compañías cambian la forma de
dirigir su negocio y cómo los clientes pueden re c ib ir rápidamente los productos de los
"'a:
~ proveedores.
>
z
:::>
z
b.3 .- Ventajas
=
u
<
o
z
..."'
Mediante la implementación de un sistema de gestión de la cadena de suministros,
integ rado y en red , las empresas pueden reducir costes, aumentar los ingresos, mejorar
el se rvicio , acelerar el tiempo de comercialización del producto y util izar sus activos
eficazmente.
La s compañías innovadoras que implement an técnicas de gestión de la cadena de

suministros se están dando cuenta de sus muchas ventajas, entre las que se incluyen:
• Reducción de costes en la gestión del inventario , transporte , almacenamiento y

embalaje .
• Incremento de la satisfacción de los clientes a través de la entrada y configuración

de los pedidos en línea.
• Mejora del servicio a través de técnicas como la entrega puntual y la fabr icación
bajo pedido.
• Aumento de los ingresos, gracias a la disponibilidad y la personalización del

producto.
DI RECCIÓN Y GESTI ÓN DE PROYECT OS TI C 215

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-BUSINESS
• Reducción de los tiempos del ciclo del producto .
• Aumento de la cuota de mercado debido a la reducción de los tiempos del ciclo de

ingeniería a producción.
• Flex ibi lidad para d iseñar, comercializar y retirar productos de la forma más rápida.
• Capacidad de mantener la calidad del producto mientras se subcontratan las partes

principales del proceso de ejecución.
CASO: FLYMO
La empresa Flyrno (wv" . ~lvrno com ) se conoce por ser los inventores del "cortacésped" flotante . Sin
embargo, a pesar de su éxito doméstico, la empresa temía por el aislamiento de su red de pequeños y
medianos distribuidores. Mientras que los grandes almacenes DYI mantenía estrecho contacto con ellos y
realizaban sus transacciones electrónicamente mediante Electronic Data lnterChange (EDI), los pequeños
distribuidores se sentían abandonados. Incluso Flyrno no estaba satisfecha con la manera en que ella misma
llevaba este asunto. Se percataron de los enormes gastos de procesar documentos de papel o fax, de los
dolores de cabeza de la administración para poder descifrar la información y del derroche que suponía haber
colocado una plantilla cualificada para realizar un trabajo de oficinista. <
z
<
~
Era obvio que algo había que hacer, sin embargo encontrar una solución inmediata no era fácil. Flyrno había "'
~
<
o
visto varios sistemas de pedidos y facturación en línea, hicieron indagaciones sobre la posibilidad de trabajar ~
con Internet e investigaron el uso de los CD-ROM corno catálogo digital de piezas. Sin embargo, nada parecía "'
~
capaz de solventar el problema que se presentaba. "'....<
¡¡;
::
Fue entonces cuando Flyrno se puso en contacto con su proveedor estratégico ABC, una conocida empresa <:
z
::>
informática, y juntos resolvieron los aspectos principales e idearon un plan de acción. El director de soporte z
técnico en la operación de Servicios de Información de Flyrno, así lo cuenta: "El plan estaba basado en las ~
V
posibilidades de Internet y lo que se podía hacer con ellas, al tiempo que abría la posibilidad de que la o<
z
::>
tecnología ya existente en la empresa se pudiera utilizar corno una extranet. También analizarnos los u..
problemas con los que se enfrentaba la empresa y ABC nos ayudó a identificar los problemas claves y a
buscar la mejor forma de resolverlos utilizando las tecnologías de Internet. El resultado ha sido excepcional".
º
Uno de nuestros principales distribuidores, con 42 centros en Gran Bretaña fue cauteloso al principio y sólo
probó con un centro piloto. Ahora ya han desplegado la extranet a través de los 41 centros restantes. De no
tener nada hace 1 año, ahora estarnos presenciando grandes mejoras, a la vez que hemos conseguido una
estrecha relación con todos nuestros distribuidores".
"Ahora los distribuidores pueden conectarse en cualquier momento del día o de la noche, sin tener que
ponerse al extremo de un teléfono ni tener que mecanografiar un pedido antes de mandarlo por fax. Las
preoctipaciones por escribir un número incorrecto, saber si el pedido se ha recibido o no o si se está
procesando han desaparecido. Desde nuestro punto de vista, ya no necesitamos personal que gestione todos
los fax y demás documentos que se reciben, que descifre la información y que, potencialmente, también
puede equivocarse. Este personal está ahora libre para atender las llamadas de los clientes finales o de los
distribuidores con problemas técnicos. De manera que con este proceso global hemos resuelto un asunto de
vital importancia para nuestros clientes".
c.- Comercio electrónico
Los clientes pueden realizar sus com pras a través de la Red. Se trata de ofrecer la
posibilidad de que ellos mismos procesen sus propios pedidos , como las demandas en
216 DIRECCIÓN Y GESTIÓN DE PR OYECTOS TIC

FUNIBER fJ ......................................... --
EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-B USIN ESS
una empresa aseguradora o los pagos en una entidad bancaria o financ iera. Este cambio
es de un enorme potencial.
Se pueden considera r estos tres procesos prioritarios como partes de un modelo de

proceso simple . Ahora , si se consideran los sistemas de planificación de recursos de la
empresa (ERP, Enterprise Resource Planning) de una compañía , como la parte central de
este modelo, entonces los sistemas de gestión de las relaciones con el cliente
habilitados para la Red o para extranet ofrecen una interfaz para las comunidades de
clientes ( ) . Un ejemplo son los sistemas de autoayuda para clientes.
--- --- CRM
K::_- SCM
<
z
< e-Commerce
~
o:
:;:
<
o
::..
::
o:
::;¡;
¡:
~
ERP
z
::>
z
·O
u
<
o
z
o
::J
IL
base tecnológica
Organización
Figura 4.7: Modelo de procesos de negocio de una solución e-Business.
En el otro extremo del modelo están los sistemas de gestión de la cadena de

suministros a través de la Red , que permiten mejorar la comunicación con los
proveedores , distribuidores y demás colaboradores de la empresa . Los sistemas de
comercio electrónico , que permiten realizar pagos a través de la web, así como otro tipo
de transacciones con toda seguridad , resultan claves tanto para las relaciones de
empresa a cliente como de empresa a empresa .

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E- B USINESS
FUNIBER
CASO: REI
REI (::ww.rei.corn ) es un minorista internacional de productos de alta calidad para los entusiastas de las
actividades al aire libre. Cuando REI decidió abrir un almacén virtual en Internet, la empresa eligió los sistemas
IBM RS/6000 para los servidores web y el software A'rewallde IBM para seguridad. Sin embargo, REI tuvo que
aprender el duro camino de las limitaciones de algún software de comercio electrónico. Tras instalar el servidor
Merchant de Netscape, REI se dio cuenta de que el sistema no ofrecía las prestaciones ni la flexibi lidad que
necesitaba. REI empezó a rediseñar su sitio web para superar estas deficiencias. Pronto se dieron cuenta de que
pasaban más tiempo intentando actualizar sus páginas que buscando la manera de mejorar sus ventas de
equipos y ropa para actividades al aire libre.
REI decidió que necesitaban cambiar sus sistemas de comercio electrónico. Tras evaluar los principales
proveedores de software comercial, REI eligió NetCommerce de IBM pro su capacidad de integrarse con
sistemas ya existentes, sus posibilidades de búsqueda y comercialización, y su facilidad de uso y flexibilidad.
Hoy, REI es una de las tiendas de la compañía con mayor producción. Más de un cuarto de los compradores
virtuales de los almacenes son nuevos para REI. Sus páginas han permitido que REI consiga nuevos clientes de
todo el mundo y que comercialice sus productos en francés, alemán, japonés y español, aparte del inglés.
Además de haber elegido el sistema adecuado a sus necesidades y objetivos, REI descubrió que la implicación
de todo el personal de la empresa es fundamental para el éxito de sus iniciativas electrónicas. REI utiliza
recursos de todas sus divisiones en lugar de disponer de una unidad separada de comercio electrónica para <
z
<
gestionar la operación. De esta forma se alienta a cada grupo de ventas al por menor para que pongan todo su u
empeño y sean cada vez mejores, a la vez que ha creado un sentimiento de propiedad y un soporte de toda la "'~
<
empresa de incalculable valor para el éxito de REI. o
"'
"'"'
<
;;:
;ó
4.2.5 FACTORES CRÍTICOS DE ÉXITO PARA UNA ESTRATEGIA E-BUSINESS "'"'
>
z
::>
z
<>
ü
A continuación una lista de factores c ríticos de éxito pa ra llevar adelante una est rategia <
e
z
e-business 3 : :>
u..
"'"'
• Un no rte claro. Crear una idea de hacia dónd e se qu iere llegar con las soluciones e-
Business. Esta idea se centra más en la mejora de los procesos centrales que en la
adquisición de las tecnologías más populares del momento. Los ejecutivos están
comprometidos con esta y son sus mejores defensores dentro de la empresa.
• El proy ecto es de toda la org anización . Las person as alred edor de la empresa se ven
imp l icadas en la transformación. No se trata de un proyecto ais lado de t i. Los
expertos y técnicos de la empresa colaboran para cambiar fund amen talmente el
modo de hacer las cosas.
• Hay que unir visión de negocios y visión tecnológica. Se requieren expertos y estas
empresas reconocen que l a transformación de los procesos centrales de la
compañía necesita más que u n webmaster. Se requ ieren las cualidades de
3. Factores Críticos de Éxito (Critica! Success Factors, CSF). CSF se definen como áreas en las cuales los resultados, si son
satisfactorios, asegurarán un desempeño competitivo a la organización. En esencia son áreas de actividad bajo
continuo cuidado y atención de la gestión. Como se puede intuir, esta definición es bastante amplia y, como el mismo
Rockart lo plantea, no es posible garantizar que el CSF de una organización sea el adecuado para otra.
Fuente: Rockart, J.F. (1979) . "Chief executives define their own data needs'. Harvard Business Review, 57 (2) : 238-241.

EJEMPLO DE PROYECTO TECNOLÓG ICO: IMPLANTACIÓN PROYECTO E-B USINESS
expe rtos , especialistas en bases de datos, gente que conozca los s i stemas
vigentes , gestores de proyectos y veteranos en el proceso de la emp resa . Cuando
sus recursos internos no disponen de la expe riencia necesaria, dichas empresas se
asocian con expertos de fuera de la empresa.
La aplicación e-Business es el medio para implantar la solu ció n e-Business. Esto impl ica
identificar cual o cuales apl i caciones serán necesarias y definir la arquitectura
informática que les dará el soporte computacional necesario.
4 .3.1 IDENTIFICAR POTENCIALES APLICACIONES
<
Para conseguir el máximo potencial de la solución e-Business es importante desarrollar
z
<
~ una visión de e-Business compa rtida y, basados en los factores críticos de éxito de la
~
>:
<
o
emp r esa, identificar y priorizar las o p o rtun idades e-Business. Es importante tener
"'w presente en este análisis que el valor de las aplicaciones e-business requiere evaluar por
"'
igual , tanto los costes tecnológ icos y los beneficios como aspectos de riesgo y de
seguridad .
• Por una parte , hay que definir la aplicación o las aplicaciones e-Business, aquél
sistema que responde de manera efectiva a las necesidades de la estrategia y que
abarca un conjunto de procesos de negocio ( ).
Aplicaciones e-Business
Administración
Personal
Sistemas
de producción Finanzas y contabilidad
integrado
Marketing Diseño y Ventas Servicio

Sistemas de logística y
segu1m1ento de productos
Figura 4.8 : Identificación y definición de aplicaciones.

E JEM PLO DE PROYECTO TECNO LÓGICO: IMPLANTACIÓN PROYECTO E-B USI NESS
FUNIBER
• Por otra parte, es necesario identificar las soluciones e-Business nuevas y

ejecutables que ayuden a implementar efectivamente la estrategia ( ).
Estas soluciones pueden ser: interfaces de web , gestores de contenido u otros
productos comerciales.
Solución ERP
Sistemas
de producción
integrado
Personal
Finanzas y contab1hdad
Marketing Diseño y Ventas Servicio

producaón post-venta
Sistemas de logistica y
segu1m1ento de productos
Herramientas de <
desarrollo ERP • s "'<
t::
V'
~
>
Figura 4.9: Alcance de las soluciones e-Business. z
::i
z
·~
:;i
o
a.- Aplicaciones e-Business z
.._::>
Cada empresa debe dete r minar cómo generar y maximizar su valor añadido durante
todo el periodo de despliegue del proyecto e-Business. En consec u encia , los planes de
implantación de los procesos variarán según las empresas y los sectores de actividad ,
adecuándose a la manera en que cada una pueda mejorar la calidad y la eficacia de su
servicio al cliente , y en función de dónde radiquen las verdaderas oportunidades de
negocio. Esto lleva a definir aplicaciones de varias maneras.
• Un banco cuya estrategia se centre en las relaciones con sus clientes agrupará una
serie de productos y servicios estratégicos para proponerlos como una oferta
unificada. En este caso , el plan de v aloriza ción e-Business comienza por el soporte
al cliente y la ampliación del serv icio, continúa con la conquista de nuevos clientes
y la implantación de facturación y pagos online , para finalmente extenderse a los
procesos de seguimiento y de generación de informes , que a su vez sirven para
modificar los procesos administrativos y las ofertas .
220 D IRECCIO N Y GESTIÓ N DE PROYECTOS T IC

f ______________________________
EJEMPLO D E PROY ECTO TEC NOLÓGICO : IMPLANTACIÓ N PROYECT O E-BUS I NESS
FUNIBER
• Un banco cuya estrategia esté enfocada principalmente en sus productos intentará

desarrollar productos financieros de masa personalizables, a fin de satisfacer
necesidades precisas de los clientes : tarjetas de crédito, préstamos, consulta de
saldo, etc. Su plan de implantación de procesos será muy diferente: enfocado
inicialmente en cómo conquistar nuevos clientes de forma más rentable y eficaz,
evolucionará hacia la optimización e interconexión de los procesos internos de
comunicación y operaciones de sus agentes comerciales. Se extenderá
posteriormente hacia el sopo rt e al cliente , tanto para el usuario fina l como para el
revendedor online , continuando con las herramientas de business intelligence para
el seguimiento comercial y los informes de ayuda a la d ecisión, para llegar
finalmente al desarrollo de nuevos productos .
A l t rab aja r con clientes de tod o el m undo las 2 4 ho ras del día, las aplicaciones e-
Business que han alcanzado el é xito comparte n una ser ie de caracter ísticas
comunes.
• Datos centralizados. Tienden a tener un servidor central de manera que
proporcionan acceso a todo el sistema una amplia variedad de clientes (browsers ,
Personal Data Assistant o PDA , sistemas telefónicos, etc .). Las aplicaciones se
integran en procesos claves, especialmente la gestión de las relaciones con el
cliente, la cadena de suministro y, de forma creciente , el comercio electrónico .
• Las aplicaciones e-Business aprovechan las aplicaciones y soluciones ya existentes.

Amplían las principales aplicaciones , incrementando su alcance y , en última
instancia , su valor . Las aplicaciones se diseñan sobre lo que ya t iene n, por lo que
pueden apro v echar sus s istemas centrales de la empresa . Simplemente los
amplían , aprovechando las aplicaciones y los datos de que ya disponen , sin
preocuparse de la forma en qué se encuentran . Diseñan sobre sus inv ersiones , no
las sustituyen.
• Permiten optimizar la carga de trabajo para cualquier servidor. Esto es posible

porque se utilizan técnicas de programa c ión basadas en estándares y las
aplicaciones se pueden trasladar de un sistema a otro sin tener que preocupa rse
por las compatibilidades del sistema operativo. Esto permite satisfacer sus
necesidades de integración, adaptabilidad y capacidad de uso .
• Crecen con la empresa. Es difícil predecir cuántas personas vi sitarán un sitio w eb

en un momento dado y es importante que la apl icación sea capaz de adaptarse . La
gente no esperará en sus páginas más de lo que espera en un número 9 0 0 .
Probablemente menos. Por eso la adaptabi lidad, j unto con la dispon ibilidad y la
seguridad de la apl icación son más importantes que nunca .

EJ EMPLO DE PROYECTO TE CNOLÓGICO: IMPLANT ACIÓN PROYECTO E-B USINE SS
FUNIBER
• Son f áciles de desarrollar y utilizar. Son dinámi cas. Cambiar confo rme la empresa
cambia y se despliegan a los nuevos usuarios que desean un funcionamiento
intuitivo y eficaz.
b.- Soluciones e-Business
Para identifica r las solucio nes e-Business se requie re un proceso de análisis del mercado
de las soluciones e-Business, el cual requiere genera r, para cada una de ella, una lista de
beneficios esperados y sus factores críticos de éxito. Aparte, es conveniente desarrollar
métricas o criterios mensurables del éxito de estas soluciones.
En una gran empresa , las soluciones e -Business, compradas y / o desarrolladas, pueden

ayudar a competir del mismo modo que otras empresas más pequeñas y más ágiles ,
facilitando un a mayor capacidad de respuesta y una comunicación más directa con los
clientes. Si es una pequeña empresa , las soluciones e-Business finalmente ayudan a
parecer más grande un negocio al proporcionarle más presencia y acceso a clientes de
todo el mundo. <
z
<
u
::;
:¡:
c.- Análisis de la aplicación <
o
..::;
<
Por la complejidad del proceso, debería hacerse uso de un esquema que repre sente las "'....<
Vi
aplicaciones de negocios y los objetivos tecnológicos de la empresa, de tal manera de "'>w
establecer la prioridad relativa de cada aplicación. z
:::>
z
"º
u
<
Con el fin de analiza r de que manera las soluciones tecnológicas subyacentes a las o
z
::>
u.
soluciones e-Business existentes satisfacen efectivamente a las aplicaciones y procesos ~
de negocios (ver ), se usa método el n-cube. En este tipo de repr esentación,

existe un eje de aplicaciones, otro de procesos de negocio y un tercero de soluciones e-
Business.
222 DI RECCI Ó N Y GESTIÓ N DE PROYECTOS TIC

E J EMP LO DE PROYECTO TECNOLÓGICO : IMPLANTACIÓN PROYECTO E-BUSINESS
Alcance del
sistema e-Business A Solución ERP
Administración
Personal
Ananzas y conti!bi~
Sistema d e
producción
integrado
base tecnológica
Marketing Diseño y Ventas Selvido - redes
producci6{l post-ventas - comunicaoones
- GUl
<
z
:
<(
o
desarrollo ERP • s sistema e-Business B
~
<(
;;:
<
!: Figura 4.10: Dimensión de las soluciones e-Business.
"'~
:::.
z
:::>
z
-O
ü<(
o
z Interfaces Transaccionales
:>
u.
:9 Servicios colaborativos
Gestión de contenidos
Servicios de seguridad de web
Interfase web
AphCilOÓn Aplicación Aplicación Aplocaci6n
Procesos de Procesos de Procesos de Procesos de

negocio negooo neqooo negooo
Ap11c:aoón Aplocaoón Aplicaoón Aplocaoon

e-Commerce y
Procesos de Procesos de Procesos de Procesos de soluciones e-Business
negooo negocio ne<JOOO negooo
---
Aplialci6n Aphcaoon Aplicación Aploc.aoón
Procesos de Procesos de Procesos de Procesos de

negooo negocio negocio negocio
Figura 4.11: n-cube4 .
4. IBM. Enlace web: htto' ffr:ww rbm com

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROY ECTO E-B USINESS
Gracias a esta representación, se puede deci r que una aplicación abarca uno o varios
procesos de negocio, mediante la utilización de una o varias soluciones e-Business. En
otras palabras , las apl icaciones y los procesos de negocio que necesitan ser
desarrollados y soportados tecnológicamente est án en el frente del cubo y cada cara
adicional representa los diferentes y va r iados componentes tecnológicos que se
necesitan por cada aplicación o, lo que es lo mismo , el alcance de aportación de la
solución en sostener determinado aspecto de la aplicación.
Muchas organizaciones t ienen un registro bastante amplio de aplicaciones que superan

con creces presupuestos y capacidad de la empresa. Por este motivo es importante
establecer prioridades para la implantación de estas apl icaciones , dependiendo de dos
t ipos de f actores:
• Factores internos como presupuestos, fuerza de trabajo , disponibilidad de recursos

y disposición organizacional .
• Factores externos como regulaciones gubernamentales, presión competitiva , ser el

primero en el mercado , etc.
Por último , para asegurar el éxito de estas aplicaciones , la organización debe construir
<
un consenso y mejorar la comprensión y el compromiso del portafolio de aplicaciones , ;;:
<
....
involucrando u haciendo participar a ejecutivos y departamentos. Vi
~
::::
z
:::>
d.- Factores críticos de éxito de una aplicación e-Business z
o
ü
o<
• Claridad en los objetivos de negocios. Un objetivo de negocio relaciona áreas a las 5
u.
cuales se busca incrementa r ganancias y disminuir los gastos , o donde hacer que
las cosas fun c ionen de manera más adecuada , guiando en todo momento el diseño
de la aplicación .
• Añadir valor . Un proyecto e-Business debe concentrarse en áreas donde se espera

obtener beneficios y ganancias . En este caso la tecnolog ía debe v er se c o mo un
habilitador y un facilitador del cambio, en ningún caso como conductor del camb io.
• Retroalimentación rápida y continua . La acelerada v eloc idad en la introducción de

nue v as tecnologías requiere que el proyecto e- Business tenga rápidamente
resu ltados para generar métricas de análisis .
• Cerrar las puertas por donde entra el agua'. En un proyecto e -Business es

imprescindible que las tareas realizadas sean bien c oncluidas evitando volver a
ellas . Esto ev ita cuellos de botella .
• Flexibilidad. Casi condición sine qua non, la flexib ilidad en un proyecto e-Business
es imperati va para enfrentar los continuos cambios tecnológicos .

FUNIBERf1; ......................................................
• Fijar hitos económicos . Apa rte de los hitos de gest ión, es conveniente establecer
hitos de natu raleza económica con contratistas y proveedores.
• Contar con pequeñas victorias. L a p resión del trabajo rápido requiere que se
puedan tener pequeñas victorias para mantener la energía en alto.
• Creación de un cambio cultural. U n proyecto de e-Business es una acción cuya

ob r a resu l tante es u n camb i o en la ma n e r a de obse r var el negocio con el
consecuente cambio de cultura.
Existe un conductor. Habitualmente un CEO (Chief Executive Officer), es conveniente

que un directivo sea un líder del p royecto de e-Business, alguien que presta atención al
proyecto y da el ejemplo. Este conductor puede ser o no el gestor del proyecto.
CASO: NORWEST
La empresa Norwest Mortgage, con base en Des Moines, Iowa, utiliza el servidor de aplicaciones WebSphere
<
z
< Application Server; Standard Edition y WebSphere Studio para desarrollar y desplegar aplicaciones
u
o: hipotecarias de autoservicio. La línea de productos WebSphere permite que los especialistas en hipotecas de
:E
< Norwest puedan enviar información sobre préstamos y verificar el estado de un préstamo desde el Web site
o
::¡ de Norwest Mortgage, las 24 horas del día, los 7 días de la semana.
:o
<
o:
~ Una vez que un préstamo se pone en marcha, los especialistas pueden verificar su estado. Un gran número de
;;;
~ las llamadas que se reciben en Norwest Mortgage son para consultar el estado de los préstamos. El ofrecer la
::
z verificación del estado en línea a modo de autoservicio ha reducido los costes de Norwest en los contactos
::>
z empresa-cliente. Los gestores pueden generar informes sobre las estadísticas de productividad individual de
9
u
<
los corretajes y los correspondientes gestores bancarios. El sistema Alliance de Lender genera informes de
o
z seguimiento del estado de los bancos correspondientes frente a sus compromisos mensuales de generación
"
u..
de préstamos.
Puesto que la solución se basa enteramente en servlet, no se necesita software de cliente. Los servlets de
Norwest son módulos de programa acoplados al servidor y escritos en Java con Visua/Age para Java de IBM
para ampliar la funcionalidad del servidor Web. Estos módulos se cargan y funcionan dentro del servidor web
y utilizan los servidores http para recibir y responder las consultas de los exploradores web de los sistemas
cliente. El servidor de aplicaciones WebSphere permite desplegar y gestionar los Java servlets y JavaBeans en
un entorno de plataforma cruzada fácil de utilizar.
Los Business partnerssolo necesitan una inversión mínima para acceder al sistema: cualquier tipo de sistema
(Macintosh, PC, Network Computelj, un explorador web y cualquier tipo de conexión a Internet. La presencia
omnipresente de Internet en las empresas actuales garantiza que la mayoría dispongan de un proveedor de
servicio Internet. Para aquellos que no disponen de él, el bajo costo de una tarifa plana permite igualmente
un acceso ilimitado sin suponer impedimento alguno. Los usuarios acceden al web site para los miembros de
Norwest con su ID de registro y la contraseña. Para proteger la confidencialidad de la información que circula
por Internet, la página soporta browsers que utilizan mensajes cifrados de 40 ó 128 bits.

E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-BUSINESS
FUNIBER
Después del período de implantación y análisis de códigos, los creadores expertos en Java de Norwest
codificaron la aplicación en 2 meses, más 3 semanas de pruebas beta sobre el terreno. El soporte de
WebSphere para los estándares abiertos permitió que Norwest pudiera diseñar sus aplicaciones a partir de su
inversión de hardware y de software ya existente y desplegar una aplicación basada en la Red con un mínimo
coste. Norwest espera recuperar los gastos de desarrollo de WebSphere en 3 o 6 meses tras sustituir el
intercambio manual de información existente por la aplicación web de autoservicio. Un grupo seleccionado de
empresas asociadas utiliza act ualmente la solución. Cuando ésta se encuentra totalmente implementada,
todos los agentes hipotecarios de Norwesty los bancos correspondientes podrán acceder al sistema .
WebSphere minimizó los gastos de desarrollo y permitió una rápida implantación al ofrecer a Norwest la
posibilidad de convertir las aplicaciones existentes en una solución e-Business de autoservicio. Las
posibilidades electrónicas de consulta de datos e intercambio de documentos de la solución permiten
compartir la información de forma rápida, eficaz, precisa y asequible entre Norwesty sus empresas asociadas.
Los agentes hipotecarios y los bancos correspondientes utilizan la disponibilidad de 24 horas al día de la
aplicación de Internet para recuperar datos e iniciar préstamos por su cuenta, reduciendo el volumen de
trabajo de los empleados de Norwest La transmisión de los documentos hipotecarios en formato PDF a través
de I nternet no sólo ahorra los costes de impresión, envío y entrada de datos, sino que además pone los
documentos más importantes de la empresa en manos de aquellos que los necesitan más rápidamente que
nunca. Como resultado, los socios de Norwest pueden cerrar más negocios con menos esfuerzo y Norwest
puede procesar más préstamos sin personal adicional.
<
z
<
V
"'
4.3.2 DEFINIR ARQUITECTURA w
:r
<
:?w
"'
::o:
Definir la arquitectu ra tec nológica que soport ará las aplicaciones presentes y futuras de <
¡...
la organización es la fo r ma concreta de crea r las oportunidades que se espera de la ~

w
>
z
solución. :::>
z
o
u
<
o
a.1 .- Proceso de definición z
:>
u.
Muchas organizaciones, con la ayuda de vendedo res y proveedo res, trat an de ir más allá
de este paso identificando y seleccionado un conjunto de productos y trat ando de armar
en conjunto una arquitectura que sopo rte las aplicaciones.
No obstante , el proceso es más comp lejo , requiriéndose:
Crear, desplega r e integrar ap licaciones y sistemas e-Business rápidamente. La

velocidad en el desa r rollo permi t e aprovecha r los cambios tecnológicos y la
experiencia de crecimiento de la empresa.
Busca r opo rtunidades de amplia r las aplicaciones o sistemas existentes, en lugar

de deshacerse de los sistemas y datos que ya tienen. Esto permite aprovechar
las inversiones de TI ex istentes. Se diseñan aplicaciones que pu eden funcionar
en múltiples platafo r mas pa ra poder disponer de la flexibi lidad necesa ria para
utiliza r distintas plataformas de hardware conforme varían las necesidades de
capacidad .
2 26 DIRECC IÓN Y GESTIÓ N DE P ROYECTOS TIC

EJEMP LO DE PROYECTO T ECNOLÓGICO: IMPLANTACIÓN PROYECTO E-B USINESS
FUNIBERff ............................................
Desarrolla r aplicaciones y sistemas basados en estándares para crear interfaces

de usuario que resultan fam iliares y fáciles de usar.
T rabajar con vendedores y / o proveedores no es una mala estrategia , no obstante la

emp r esa está limitada a lo que le of r ece n , en cuyo caso, puede ocurrir, que la
arquit ectura fina lmente seleccionada esté pobr emente planificada , sea inflexible y no
p ermi t en un escalamie nto que sopo rt e las cambia ntes y evolutivas necesidades de
procesamient o de la emp r esa , debido a no haber seguido un proceso de selección y
definición más completo y que haya considerado todo el mercado de aplicaciones
info rmáticas y de e-Business existentes.
a.1.1 .- Entorno ampliable , dis ponible y seguro
Cuando se trabaja con aplicaciones e-Business, tanto si se crean como si se compran e

integran, se desea que todas las platafo rmas funcionen como una plat afo rma única , de
manera que los usuarios no noten ninguna diferencia en la capacidad de respuesta,
<
z fiabilidad , funcionalidad o interfaz. Simplemente que se den cuenta que la aplicación
<
!:
~ funciona con más eficacia.
"<
o
~ T odos deseamos que nuestros sistemas se puedan ampliar. Añadir capacidad adicional
conforme las visi t as a las páginas web aumentan o añadir capacidad según la demanda,
de tal manera que si las necesidades cambian dramáticamente de hor a en hora , aún se
pueda continuar haciendo negocios.
Deseamos que la gestión sea lo más fácil posible. Y que los sistemas sean seguros de
pr incipio a fin.
Las oportunidades son numerosas. Gest ión fácil, entornos seguros y, como punto de
partida , un entorno más rentable .
a. 1 .2 .- Desarrollo y ejecu ción flexibles
Al desarrollar y poner en marcha las aplicac iones e-Business , se necesitan v arios

tamaños de procesadores.
Es conocida la historia de los servidores en ordenadores personales. Aunque algu nos

incluso ofrecen una dispon ibilidad del hardware del 99 % , hay sistemas PC que tienden
a funcionar con alrededor del 97 % de disponibilidad. Esto está bien para un entorno de
t rabajo en grupo o de desar rollo. Sin embargo , cuando una aplicación debe servir a un
gran número de usuarios y se esperan niveles de t ransa cción aún superiores , la cosa
cambia.
DIRECCIÓN Y GEST IÓN DE PROYECTOS TI C 227

E JEMPLO DE PROYECTO T ECNOLÓG I CO : I MPLANTAC I Ó N PROY ECTO E-B US I NESS
FUNIBER
Aquí es cuando la calidad y la fiabi lidad del servicio que ofrecen los sistemas de
empresa y de gama media adaptables se convierten en algo sumamente importante.
Ampliar la capacidad de las aplicacion es añadiendo un servidor PC tras otro crea
sistemas cada vez más complejos. Estos sistemas pueden ser menos fiables y necesitan
un soporte más caro .
Cambiar a un servidor de gama media adaptable como, por ejemplo, un AS / 400 , puede
proporc ionar más capacidad de almacenamiento, más potencia de procesamiento y la
posibilidad de ejecutar múltiples aplicaciones de forma simultánea. La disponibilidad
media de estos servidores de gama media llega hasta el 99,97 % . En un entorno de
producción, esto supone una enorme mejora.
Para cierto tipo de aplicaciones , un mainframe puede ser la mejor solución. Por ejemplo,
con un S/ 390 , las aplicaciones se pueden ejecutar en el servidor manejando un gran
número de transacciones y con un grado casi perfecto de disponibilidad y de fiabilidad
del 99,997 % . Y en muchos casos, el S/ 390 ofrecerá el menor coste por unidad,
<
dependiendo del volumen de transacciones que manipule el sistema. z
<
~
:::;
:i:
<
Así que cuando se desee crear aplicaciones en servidores PC e incl uso desplegarlas o
5
inicialmente en los PC, deseará que sea n lo bastante flexibles como para poderlas "'
<
;;
traslada r más tarde a un servidor de mayor volumen si la situación lo requiere. <
~
5"'>
z
b.1 .- La arquitectu ra e -Business :::J
z
·O
u
<
o
La arquitectura a definir debe soportar las aplicaciones en Web, intranet y extranet que z
"
LL
provean ciertos servicios básicos, de tal manera de proveer y soportar un se rvicio al

c liente 24 horas al día los 365 días al año , además de accesos eficientes a los clientes
habituales y a los millones de nuevos de clientes potenciales en cualquier momento y en
cualquier lugar.
Para ello se propone una arquitectura que cuente con servicios de tres tipos, los cuales
pueden implementarse en tres capas (layers) según la función que cumplen. Estas capas
son ( ):
• Capa de servicios de infraestructura.
• Capa de servicios habilitadores.
• Capa de servicios de aplicación.

EJ EMP LO DE PROYECTO TE CNOLÓGICO: IMPLANTACIÓN PROYECTO E- BUSINESS
FUNIBERff
------------~c:ED:------------------
Servicios de aplicación
HTML&
DKTML
J JavaSoipt &
VBSoipt
Componentes
ActiveX
Java Applets
CGI Scnpts Servidores de Java Beans&

f NSAPI, ISAPI páginas Servelets
Servicios habilitadores
Gestores de
Monitor Gestor de Servidores
correo & mensajes
Gateways TP web
Servidos de
Gestor de Base de ORBs
trabajo en
world'tow datos
grupo
<
z
<
!::!
5 Infraestructura de servicios
:>:
<
o
"'w Directorio Seguridad Rchero DCOM CORSA
"'
<
"'<>- Gestor de sistema de d1stnbuaón
Vi
5> Servicios OS Base
z
::>
z Servicios de red
-o
u
<
o
z
::>
u..
Figura 4 .12: Arquitectura lógica para arquitecturas e-Business.
b .1 .1 .- Capa de servicios de infraestructura
Esta capa provee los servicios básicos requeridos para implementar aplicaciones dent ro
de la organización. Consiste en:
Servicios de redes basados en protocolos T CP/IP.
Servicios básicos provistos por el sistema operat ivo para gestión de recursos de
hardware y software.
Servicios de Gestión de Sistemas Distribuidos q ue ayudan a proveer un

mecanismo consistente y conso lidado de manuten ción y so porte de los recursos
de computación distribuidos.
Servicios de Directorio que ayudan a localizar recursos en el am bi ente

distribuido.

EJEMPLO DE PROY ECTO TECNOLÓGI CO: IMPLAN TACIÓN PROYECT O E-BUS IN ESS
Serv icios de Seg uridad que controlan el acceso a recu rsos distribuidos y
prot egen los recu rsos de la o r ga n ización de accesos no autorizados, tanto
internos como externos .
Las presiones por proveer servicios que disminuyan la carga y provean seguridad en ambientes distribuidos
por naturaleza, como lo es una aplicación e-Business, ha llevado a determinados proveedores a
configuraciones como la que aquí se muestra (Novell's Internet Cache Systems, ICS).
La complejidad de un sistema cache, lo cual involucra diversos elementos técnicos, es una tarea compleja,
más aún cuando se ven involucrados variables de costo y experiencia de usuarios y desarrolladores.
Una tendencia en almacenamiento son las redes de almacenamiento (Storage Area Network, SAN),
integrando tecnología de canal de fibra y los medio ambientes heterogéneos de almacenamiento. La finalidad
es distribuir el almacenamiento a través de diversos medios y formatos.
<
z
<
!:!
e¡
>:
<
o
.
;:¡
<
;;
<
;;;
~
>
z
:::;;
z
-O
u
<
o
172 16 96 ()119 172 16 32 ()11 9 z
::>
LL
Figura 4.13: Ejemplo de Arquitectura Cache Proxy5 .
s. IDRST. (2010). Caching Proxy Architecture far !CT4RD. Network. ICT 4 Rural development SURUCA team.
Diciembre 16.
Enlace web: r':t~· yrn - 12c; y.:>n swt.i<th se csd 1v<> s.<es C.::>fat. t ' es ~ ro 1 ec:~ Caen ~gc:eryerArcn1:ecurev2 E nal odf

FU NI BER ~ ¡¡¡;¡¡¡¡¡¡¡;¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡;E¡¡J•EM¡¡P¡¡L¡¡o¡¡o¡¡Em;P;::;Ro;:v:i;:E:c::r:.o;:r::::1E::ccN:o:1Lo•·G•1 c•o•:•1M•PL•A•N•T•Ac•1•ó•N•P•R•o•v•E•cr•o•E•-s u•s•1NE•s•s
11 11 11
~
Load Balancer
Apache/Weblogic/Jboss Web Farm n

Scale Web Farm Horizontally
<~=================================~
Jlíl Demand
20,000 request/sec
<
App Data
z
<
~
~
"'
<
o Capadty
~ 10,000 requests/sec
"'~
> Database Servers
5
z
':?
u Figura 4.14: Ejemplo de Escalabilidad con cache distribuido6 .
<
o
5
u.
6. KAHN, IQBAL. (20 12). How to Sea/e Java App!ications with Distributed cache? En Alachisoft. Enero 6.
Enlace web: hi:p;/ w1." .alach1soft CO"" blogs· ncarne h01•,-to-scal"'·Java -apol1cat1ons- 1-cistr b1.ted-cache/

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECT O E-BUSINESS
FUNIBERf1
Servidor
Red de área de
almacenamiento
<
Figura 4.15 : Ejemplo de red de almacenamiento7. "'<....
Enlace web: ¡¡;
5>
htto: //computooractico. blogspot.com .es/ 2009/ 08/ccna -l -219-redes-de-area-de.html z
::::i
z
<>
ü
<
Serv icios de Ficheros que prove en una visión unificada para el uso y o
z
::>
"-
manutención de dispositi vos de almacenamiento distribuido como discos duros,
CD-ROM y cintas .
Ambientes de Computac ión Distribuida (DCE , Distributed Computing

Environment) como CORBA de OSF (Open Software Foundation 8 ) o DCOM
(Distributed Component Obje ct Mode/ 9 ) de Micro s oft que ayudan a los
desarrolladores a construir, probar e implantar aplicaciones de computac ión
distribuidas .
7. PCM. (2011) . Parque Científico de Murcia. Enlace: bttp:/ se fpcmurestin1cio/ ndex.aspx

8. OSF es una organización cuyo propósito es fomentar y, en algunos casos, desarrollar tecnologías de software que
puedan servir con fines industriales y, más aún, como eventuales estándares nacionales e internacionales. OSF ha
desarrollado una plataforma de uso industrial para computación distribuida, la Distributed Computing Environment
( DCE).
9. DCOM (Distributed Component Object Model) es un conjunto de conceptos e interfaces de programas de Microsoft con
los cuales objetos en aplicaciones cliente pueden solicitar servicios de objetos en aplicaciones servidor ubicados en
otros ordenadores en una red . DCOM se basa en Component Object Mode/ (COM), el cual provee un conjunto de
interfaces que permite a clientes y servidores co municarse dentro de un mismo ordenador.
23 2 DIR ECCIÓ N Y GESTIÓ N DE PROY ECTOS TIC

Al desarrollar un conjunto de propuestas de selección de herramientas, los gestores del proyecto e-Business
deben enfocarse en proveer a sus desarrolladores un rango de soluciones que permita una selección
adecuada. Por ejemplo, seleccionar soluciones construidas sobre una arquitectura de componentes común
(Java/ Enterprise JavaBeans, EJB/J2EE) versus Component Object Mode/ (COM) o CORSA lo cual facilitará la
integración entre aplicaciones y simplificará la migración de aplicaciones entre herramientas, si fuese
necesario.
APLICACIONES SIMPLES APLICACIONES COMPLEJAS

Necesidad de integración
Vl
~
o
~
m Orade A.S.3
oo::: Bluestone Sapphire/Web,
c..
Vl
Apple WebObjects IBM TXSenes, BEA Tuxedo,
w Forté, Hitachi TPBroker
< z
z
< o Netscape A.S
!e u
~ ;:)
....J
Sun/ Netoynamics
J:
<
o
oVl
.,::¡
<
~ Vl
"'~ w
f-
>
z
zw IBM WebSphere Adv., IBM WebSphere Ent., BEA
::> (!)
z o::: BEA Weblogic Server WebLog1c Ent., Orade A.S.,
o w
ü ¿ iPlanet, lona 1Portal A.S.,
< w
o Persistence, lnprise, IBI,
z Mercator/Novera,
:>
u.. !fl Progress Appbvity Gemstone/J, Sybase EAS,
z
"'
"' o Microsoft DNA/200,
o
;:) SilverStream Object Space Voyager
..J
oVl
Figura 4 .16: Ejemplo de organización y segmentación del mercado de servidores de aplicaciones.
b . 1.2.- Capa de servicio s habilitadores
Est a capa provee los servicios requer idos para so po rtar las aplicaciones des arro lladas
dentro de la arquitectura. Consiste de:
Gestores de correo electrónico que proveen los servicios de cor reo y gateways que
permiten la comunicación con otros sistemas de correo electrónico.

E JEMPLO DE PROYECTO TE CNOLÓGICO: IMPLANTACIÓN PROYECTO E- B USINESS
FUNIBER
Servi cios de Workgroup , los cuales incluyen fun ciones de manutención de calendario ,
compartir dispositivos y recu rsos, grupos de discusión, boletines y otras funciones que
permiten la colaboración dentro de los workgroup s.
Gestor de Workflow, el cual ayuda a co nfigurar lo s procesos de negocios como

sec ue ncias de tareas interelac ion adas que requiere n ser ejecutadas en un a
secuencia predefi nida.
Monitor de T ransacciones que gestiona las t ransacciones 10 en un medio

distribu ido y ayuda a mantener la integridad de los datos fuente . Los monitores
son v itales cuando :
m ás de una base de datos es act ua liza da dentro de una transacción ;
ex isten transaccio nes en línea;
cua ndo la arquitectura soporta aplicaciones que tienen más de dos tier 11
lóg icos ; y ,
<
cuando más de un máqu ina procesa una transacción . ~
u
§
Servicios de cola de mensajes que garantizan que los mensajes son entregados. "'<o
Serv icios de base de datos que permitan y so porten el almacenamiento y
.
::¡
recuperación de datos . Estos servicios operan sobre esquemas de bases de

..:::
<
t
Vl
datos de redes , jerá rq uicos, relaciones u objetuales. ~
::
z
::::;¡
Servidores w eb que prov ean soporte para todos las faci lidades de red como z
·O
HTTP, ftp , scripts y JAVA . u

o<
z
::>
IL.
b. 1 .3 - Capa de servicios de aplicación .,,

.
'-'
Esta capa provee servicios que permiten a los desarrollador e s de ap l icaciones

de sarrollar, probar y desplegar aplicaciones e-Business . Estos serv ici os in cluyen:
- Soporte para HTML y DHTML (dynamic HTML).
- Script para clientes los cuales sopo rten , por ejemplo, JAVAScript .
- JAVA applets , JAVA beans y JAVA Serv elet Support .
- Script para servidores con soporte CGI , NSAPI e ISAPI.
- Soporte para compone ntes Acti veX y A c tive Server Pages.
10. Transacción: secuencia de actualizaciones que necesitan ser ejecutadas como parte de una misma unidad lógica de
trabajo.
11. Tipo especial de arquitectu ra cliente/ servidor que consiste de 3 procesadores diferentes y distinguibles, cada uno
corriendo en plataformas diferentes.
234 DI RECC IÓN Y GESTI ÓN DE PROYECTOS TI C

E JEMPLO DE PROYECTO TECNOLÓGJCO: lMPLANTAClÓ N PROYECTO E-B U SlNESS
Entre los factores a tener presente en la selección de componentes se incluyen:
La natu raleza del entorno o medioambiente de procesamiento dentro de la

organización . Por ejemplo, homogéneo o het erogéneo.
La n aturaleza de las aplicacio nes qu e necesitan construirse. Por ejemplo, se r

desa rr o l la d as d e mane r a i n teg rad a con a pl icaciones exis t en tes (legacy
ap plication s).
Niveles de habil idades en la organización respecto de T ecnologías de la

Información. Podemos preguntarn os:
¿Cuáles son las habi lidades en Internet y computación distribuida que se

poseen?
¿Los programadores están familiarizados con el diseño y desarrollo de

aplicaciones orientadas al objeto?
¿Qué tipos de habilidades son necesarias para construir aplicaciones pa ra el

procesamiento de transacciones existen? ¿en CICS, 082 , IMS?
<
~
u
§ ¿Qué niveles de serv icio necesita n se r provistos por las aplicaciones e-
:r
<
o Business?, por ejemplo:
..
~
~ ¿Los clientes necesitan acceder a info rm ación actual?

"'<>-
¡¡;
~
¿Necesita el cliente acceso inmed iato a info r mación actualizada?
~
3 T ransacciones online.
z
·O
u
<
o
z T ransacciones asíncronas.
"
u..
Soporte de e-Mai/ y t rabajo colabo rativo.
Esca labilidad de las ap licaciones.
Coste total, que incluye costos inicia les de hardware y de software, costes
del hardware de red, costes de soporte y manutención , costes de
act ualización de hardware y de soft ware y , costes de rol/out.
c .- Fact ores críticos de éxito de un a arquitectu ra e -Business
• Part icionabl e. Las aplicaciones se encuentran fragmentadas, cuyo funcionamiento

integrado y consistente debe soportar la aplicación , en razón de la evaluación
coste/ beneficio de escalabilidad y disponibilidad.
• Escalable . La arquitectura debe proveer niveles aceptables de escalabilidad en el
desempeño de mú ltiples usuarios y con altos volúmenes de transacciones. Esto
incluye la integ ración con hardware, software y aplicaciones diversas . Es decir, un
crecimiento en la capacidad según la dema n da , para gestionar el volumen de
D lRECClÓN Y GESTlÓN DE PROYECTOS TIC 2 35

FUNIBERf~
EJEMPLO DE P ROYECTO TECNOLÓGICO: IMPLANTAC IÓN PROYECTO E-B USIN ESS
trabajo conforme las necesidades de la emp resa c recen y garantizar así la continua
disponibilidad de l sistema.
• Flexible . La arquitectura es abierta y soporta la incorporación de nuevas tecnologías

y productos conforme lo requie r an los diversos procesos de negocio que se
integren. La arquitectura también asegura que los servicios provistos deben estar
disponibles a clientes GU I, Web browsers, Voice Responde Units y cualquier otro
tipo de clientes.
• Confiable . La arquitectura provee soporte confiable y seguro para todos los

usuarios. La confiabilidad debe garantizar un soporte atómico, consistente, íntegro
y durable (ACID 12 ) de todas las transacciones ejecutadas entre los múltiples
gestores de recursos (aplicaciones legacy, ERP, bases de datos, etc. ). En concreto,
la infraestructura debe ofrecer un nivel de seguridad adecuado pa ra satisfacer las
necesidades del comercio electrónico y salvaguardar datos.
• Disponible . La arquitectura debe soportar capacidades operacionales consistentes

con los ni v eles de servicio aco rdados para la apl i cación con un 99 . 99 % de
<
z
disponibilidad las 24 horas del día, los 365 días del año. Si la infraestructura que da <
u
el soporta "cae" , deberían recuperarse y re-establecerse las aplicaciones dentro de 5

z
"
un lapso de tiempo razonable. ~
<
• Accesible . La aplicación debe ser accesible desde cualquier lugar. El tipo de o:
<
....
dispositivo cl iente no debe ser un problema. "'"'
~
z
::>
• Gestio nab le. Se necesita una gestión única para poder gestionar fácilmente z
~
múltiples plataformas . La arquitectura es soportada por un conjunto de u
<
o
z
herramientas comerciales disponibles come rcialmente las cual han de simplificar las ::>
u..
funciones de gestión de los sistemas para los componentes distribuidos de la "'"'

arquitectura. Esto incluye in ic iar y detener servicios , iniciar automáticamente
recuperac iones, mon itorear y reportar errores , distribuir y afinar (tuning ) el
software, etc.
• Recu pe rable . La arquitectura provee funciones de detección y recuperación de
errores para todos sus servicios . Esto debería asegurar que la integridad
transaccional y de la base de datos se preserva en los procesos de re-inicio (re -
start) y recuperación (re- backup) del sistema .
12. ACID (Atomicity, Consistency, Integrity, DurabilitYJ.

En la Economía en Red el éxito depende de quién primero alcanza con éxito el mercado.
Por ello no es ext raño que muchos productos fracasen porque se llega tarde, fuera de
oportunidad o sencillamente porque no se f ue eficiente en alcanzar el mercado.
Pa ra desa rr olla r y desp lega r aplicaciones e-Business exitosas es necesario un plan

táctico que directamente equipa re, po r un lado , las estrategias organizacionales y las
demandas de mercado y, por otro lado, los objetivos de TI. En otras palabras, conseguir
un equilibrio al momento de construir la solución e-Business entre, por una parte , el
negocio y la urgencia de mercado, con la pureza arquitectónica y la e xc elencia
tecnológica.
4.4.1 DESARROLLO
El desar rollo de la solución e-Business involuc r a un plan táctico y un programa de

desarrollo.
.:5
< a. 1 . - Crear plan táctico
"'~
::z
=>
Comience dando un pequeño paso y crezca rápidamente. La transi c ión hacia el
5
ü
e-Business debe realizarse progresivamente. Las empresas y personas impl icadas en la
<
o
z implantación y uso de aplicaciones e-Business aprenden a medida que avanza el
...."
proyecto. Pocas empresas se arriesgan a lanzarse a gran esca la , sin garantías, en el
nuevo universo e-Business. La filosofía de "comenzar dando un pequeño paso y crecer
rápidamente " es tan común como eficaz .
Las empresas que ya tienen una amplia experiencia en e-Business hacen hincapié en la
importancia de contar con una v isión o est rategia de futuro . Es la única m anera de
garantiza r que su inve rsión en e-Business sea vál ida y eficaz. La estrategia e-Business
debe desarrollarse desde el primer momento, lo antes posible en el proceso de
im plantación , y servi r le de guía para r egula r las fases suces ivas de su proyecto
e-Business.
Por este motivo, el plan táctico requ iere considerar v arios elementos:
Los objetivos estratégicos de la organización y las prioridades re lati vas.
Los beneficios para el negocio de estas aplicaciones.
Los atrasos e inconven ientes de aplicaciones actuales.
DIRECCIÓN Y GESTIÓ N DE PROYECTOS TIC 23 7

FUNIBER~
E JEMPLO DE PROY ECTO T ECNO LÓGICO : I MPLANTAC I ÓN PROY ECTO E-B US I NESS
Las habilidades de la organización de entregar y soportar tales objetivos

(presupuestos, recursos y habilidades).
El plan táctico debe enfocarse en entregar las aplicaciones e-Business comenzando de

forma creciente desde la más simple. Cada esfuerzo de desarrollo debería ser medido en
tareas concretas y específicas que respondan coherentemente con los objetivos de
negocios.
Por este motivo se recomienda diseñar la arquitectura de manera fundacional , tal como
se hace en la construcción de edificios, de tal manera de tener una sól ida y fuerte base
sobre la cual, y a partir de ella, introducir las tecnologías y servicios necesarios para el
adecuado desarrollo de todas y cada una de las aplicaciones e-Business ( ).
Con este mecanismo de trabajo se puede mantener a la organización focalizada o
pendiente de los objetivos del negoc io minimizando cualquier distracción que conlleve la
introducción de las tecnologías y servicios. Básicamente es no convertir el medio en el
objetivo.
<
z
."'

z
.
SI/TI
.
·O
ü
<
o
z
Clientes
.. ..
Proveedores ::>
LL
Productos/ Partes/
. ~:
Servicios Servicios
¡~
Sistema de información
: ·~)_.
de empresa integrado
Figura 4.17: Arquitectura de un sistema e-Business.
El resultado de este paso es un plan de proyecto de alto nivel y una propuesta de

implantación en fases para todo el portafolio de aplicaciones e-Business. Este portafolio
ha de reflejar las prioridades del negocio , el presupuesto organizacional dedicado al
proyecto y las restricciones en recursos. También ha de incluir una sección con un
análisis de recursos y requerimientos de habilidades y recomendaciones sobre cómo
gestionar los recursos.
238 D IRECCIÓN Y GESTIÓN DE PROYECTOS TI C

FU N 1BE R ff ------
EJ· E·M
· P· L·º · º· E
· P·R·O·YE
· C·T·º- T.EC
·N·O·L·Ó·G·I·
CO- : .IM·P·L·A·N·
T·A·Cl·Ó·N-PR·O·Y·E·C·T·O·E
· -·B·U·S·JN·E·S·S
b. 1 .- Program a de d esarrollo
La muestra un programa de desarrollo.
Publicación en la Web e- Business
A. Conoomiento e.Presencia l. Fase piloto
• Utihz.loon interna · Creaoon de un - Aderuaoon ele la · Transacoones • 1nteracoon · Integración de los

intemet Web sote informaaón para para d.ernes en personall.!ada puntos de cont3Cto
los dientes "autosetVICJO" con el doen:e de los dientes
· lnteg<ación y "hmp¡eza• · Anahs1s ele la · lntegraoon en la
de las bases de datos fidelidad de los callena ele suministro
de el.entes dientes · Creación de un unteo
Acceso del cliente Percepoon que punto para P<.'didos
en "autoserviao· tiene el diente 1 servioo al 01ente
(self·service) a las de la emp<esa • Enlace con los sostemas
bases de datos de los colaboradores
para ofrecer a los dientes
una v1S>On unificada ele
la emp<esa
<
z Incremento de la lmportllnda del lle!lodO

z
o descubren en seguida el potencial de la Red para estab lecer u n as relaciones más
ü
<
o
z pe r sonales , eficientes y competitivas con sus clie ntes . Esta toma de conc ienc ia
"'
u.
constituye el punto de partida de su proyecto e-Business.
En la fase piloto , las empresas centran su atención en preparar la información pa ra

hacerla accesible a sus clientes como un verdadero " autoservicio". En el sector de los
transportes aéreos , por ejemplo , las compañías aéreas han c omenzado simplif icando la
info rmación sobre salidas / llegadas de sus vuelos , de modo q u e sea d irectamente
accesible para los clientes online.
Du rante la fase de implantación , las empresas abren estas bases de datos estratégicas a
sus clientes y /o colaboradores y proveedores para efectuar t ransacciones u operaciones
comerc iales electrónicas , Por ejemplo , las compañ ías aéreas ofrecen reserv as online , y
los bancos servicios interactivos. En esta fase , los clie ntes pueden co m prar y efectuar
transacciones online siempre que lo deseen , y la empresa a su vez adquiere
conocimientos inestimables sobre las necesidades y el com portamient o de sus c lientes .
Gracias a lo anterior , la empresa puede clasificar a sus c lientes de acuerdo a su

comportamiento y rentabilidad . Sin emba rgo , si no se hace el esfuerzo inicial de adecuar
la información a los clientes , las ventajas de esta interacción , aunque reales , serán
DIR ECCIÓN Y GESTI ON DE PROYECTOS T IC 2 39

E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROY ECTO E-B USINESS
FUNIBER
mínimas. Numerosas empresas han comenzado a ofrecer t ransacciones online a fin de

disminuir sus costes, pero sin contar con el punto de vista de sus clientes. Por esta
razón, no han logrado de ellos una actitud comprometida y los resultados no han sido
tan buenos como esperaban.
Durante la fase de optimización de los procesos , las empresas ya poseen información

precisa sobre sus clientes y han integ rado sus herramientas de Business intelligence ,
sus métodos de análisis y sus conocimientos . Estas condiciones ideales hacen posible la
mejora del proceso de gestión de las relaciones con los clientes, pudiendo personalizar
las interacciones online y ofrecer al cliente una visión unif icada de la empresa.
A tra vés de tales interacciones personalizadas, puede apl icarse un análisis de fidelidad
para servir al cliente de un modo m ás efectivo de acuerdo a sus necesidades, en lug ar
de integrar la información una vez que el proceso ya ha concluido .
La integración horizontal de los procesos, la cuarta fase en la evoluc ión de e-Business,

se centra en la integración de todos los procesos internos de la empresa , así como de <
z
<
los procesos de los clientes. Para la empresa, esto sign ifica la integ ración de todos los u
"'~
puntos de contacto de los clientes con el conjunto de sistemas operativos , desde el <
o
abastecimiento y el cu mplimiento de un pedido hasta la satisfacción del cliente. ..::;
En cuanto al cliente, esto implica el establecimiento de enlaces con y entre los sistemas
de todos los proveedores involucrados en el proceso . Así, las compañías aéreas han
comenzado a integ rar , internamente, sus sistemas de reservas con sus programas de
fidelidad , conectándose a continuación con los sistemas de sus partners colaboradores
a fin de ofrecer a los clientes la comodidad de un punto de se rvicio úni co. A su vez, los
Q
bancos están integrando todos sus servicios para ofrecer a sus clientes una gama más
amplia de transacciones online accesibles desde un único punto central .
4.4.2 CONSTRUIR LA SOLUCIÓN E-BUSINESS
El negocio electrónico o solución e -Business no es solamente el uso de tecnología de

punta y el análisis de procesos sometidos a una re-ingen ie ría para el desarrollo d e
nuevas y revolucionarias aplicaciones sin frontera s de tiempo, espacio y geografía. La
implantación y soporte de estas soluciones es un enfoque analítico e intensivo de
desarrollo de aplicaciones que pretende conside rar ( ):
• Planificación de Negocios.
• Planificació n de Mercado .
• Planificació n Tecnológica .
• Planif icación de Operaciones .

EJEMPLO DE PROYECTO TECNOLÓGICO: IM PLANTACIÓN PROYECTO E-BUSINESS
FUNIBERff
---------------------------------
- Definir iniciativas - Investigación de mercado
- Bosquejar la visión y - Focalizadón en audiencia
los objetivos objetivo
- Justificar iniciativa - Comunicaaón de aud1enoa
- AJuste estratégico - Estrategia de medioón
- Posición competitiva - Re.ladones públicas
Negocios Marketing
Operaciones Tenología
- Staff de apoyo - Arquitectura

- Requerimientos de - Estándares de tecnologías
habilidades - Diseño y Look & Feel
- Políticas y procedimientos - Equilibrar infraestructura
- Estructura organizacional - Relaaones públicas
- Desarrollo de aplicaaones
<
z
<
~
~
:E
<
o Figura 4.19: Planificación de la implementación e-Business.
.
~
:!.
"'t:< a.1 .- Planificación de negocios
V>
5
>
z
=> La Planificación de Negocios valoriza el impacto de negocios de la aplicación. En esto se
z
o
'o:i. incluye:
z
::>
"'-
9 Identifica r los beneficios de la aplicación, mostrando su ajuste y adecuación a la
estrategia corpor ativa de negocio, y señalando en qué medida ayuda a conseguir
sus objetivos.
Comprender el alcance de los procesos de negocios que soporta la aplicación.

Esto es útil para establecer el impacto de la aplicación . Lo importante aquí es
que la aplicación resuelva un problema y / o ayude un objetivo de negocio y no
produzca problemas .
Establecer relaciones de trabajo y acuerdos de servicio con proveedores,

vendedores y partners relacionados y/o afectados por la solución.
D IRECCIÓ N Y GESTIÓ N DE PROYECTOS TIC 241

EJE MPLO DE PROYECT O TECNOLÓGICO : IMPLA NTA CI ÓN PROYECT O E-B US I NESS
FUNIBER
b . 1 .- Plan ificación de mercado
La Planificación de Mercado analiza de qué manera introducir al mercado la aplicación e-

Business según la población de clientes/ usuarios. Esto incluye:
Identificar el mercado objetivo .
Definir procesos de comunicaciones internos y externos. Se trata de identificar

de qué manera se puede conduci r el tráfico en el sitio. Esto inc l uye una
estrategia de comunicación inicial y una estrategia de comunicación efe r ente.
Estrateg ias pertinentes pueden ser: darse de alta en bus cadores populares y
espec ializados, publicitarse en sitios w eb co n altas tasas de v isitas, en páginas
web de grupos ind ustri ales, m ensajería electrónica , TV , radio , prensa, et c . Otro
medio es proveer incentivos a cl ientes y partne rs por usar la so lu ción web en
lugar de llamar a un centro de llamados.
Definir los criterios para medir el éxito de la aplicac ión.

<
z
<
~
c . 1 .- Planificación tecnológica ::;
"o<
El proceso de Planificación Tecnológica busca cómo u sar la aplicación y extender la
"'
w
"'<
;;;
arquitectura. Este proceso incluye: <
"'"'
>
Identificar los componentes de la arquitectura . z
:>
z
·:::u
Refinar los estándares de desarrollo de la aplicación. o
<
z
:>
u..
Determinar los niveles y medios de interacción con el siti o web.
Planificar el desarrollo de la aplicación.
d.1 .- Planificación de operaciones
La Planific ación de Operac iones incluye :
Determin ar requerimientos de habilidades para el desa rrollo de la aplicación ,

soporte continuo y actividades de m anutención.
Definir pol íticas y procedimientos p ara m anutención de la aplicac ió n, soporte y

gestión de sistemas .
Buscar opciones para manutención continu a como ISP (Internet Servic e

Providers ) y WebHosting y /o Outsourcing estratégico.
Ini ciar procedimientos de Gesti ón del Cam bio con el f in de comprender el

alcanc e de los cam bio s que impl ica la aplicaci ón en los ro les de los usu ario s y en
el trabajo realizado.
242 D IRECCIÓN Y GESTIÓN DE PROYECTOS TI C

E JE M PLO DE PROYECTO TECNOLÓGJCO: lMP LANTAC I ÓN PROYECTO E-BUSJNESS
FUNIBERff
------------------------------------
4.4.3 FACTORES CRÍTICOS DE ÉXITO
• Servicio 24x7. Con un potencial mundial de acceso , toda aplicación y sus webs, o
cualquier interface de acceso público debe ser 24x7, inclusive aquellas que tienen
bajo índice de consulta. Esto plantea el r eto de la mantención continua para
muchas aplicaciones negocios e incrementa la demanda po r so luciones de alta
disponib il idad.
• No hay aplicación segura . Cuando cualquiera en el mundo puede acceder a

nuestras aplicaciones, toda falla tiene efecto mundial , con sus consecuencias de
pérdida de ingresos y retornos , independiente de lo exitoso que haya sido la
captura y manutención de clientes y el buen desempeño ante un alto tráfico.
• Lo cierto es la incerteza . Otra consecuenc ia de la ubicuidad de las aplicaciones es

la incerteza de cargas, dejando KO toda previsión y planificación, tanto para
aplicaciones centralizadas c omo distribuidas. De hecho, es im posible prever todos
< los factores que afectan la carga de una apl icación.
:¡
~
5
:i: • Riesgo de seguridad siempre posible. Con todo el mundo tratando de entrar en
<
o
~ diversos sitios, hay que tener los mejores procedimientos de chequeo y técnicas de
~ encriptación de datos y claves posib les.
...<
¡;;
5
::z
:>
z
•!:
V
<
e
z
::>
u..
La cuarta etapa es aprovechar la experiencia, aprender de lo rea lizado. En cada empresa

hay una enorme cantidad de datos. No solamente en las bases de datos y en los cajones
del escritorio, sino también en las personas: empleados, proveedores y distribuidores.
El entorno e-Business pres enta una oportunidad única para crear una cultura de la
implicación propia. Una cultura que llegue directamente a todos nuestros clientes. Que
haga uso de toda la información de que se dispone para dar a la empresa una ven taja
competitiva.
Con el fin de aprovechar verdaderamente la experiencia , es necesario capturar todo el

conocimien to de la empresa y compartirlo por toda la empresa. Ha y que dar marcha a
un proceso de aprender de la experiencia, para lo cua l es necesario captu rar y analizar la
inform ación, p one r esta información a disposición de quien la necesite, y comparti r los
resu ltados con toda la empresa.
DIRECCJÓN Y GESTJÓN DE PROYECTOS TI C 243

E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANT ACIÓN PROYECTO E- B USINESS
FUNIBER
El conocimiento organizativo se plasma de formas muy distintas y tiene muchas

aplicaciones distintas. En su forma más simple , pensamos en la gestión del
conocimiento como una forma de capturar la experiencia humana y, a continuación ,
compartirla bastamente por toda la organización. Puede ser cua lquier cosa , desde la
memoria de la empresa hasta la experiencia y la información que conduce al cambio
cultural.
Los conocimientos inteligentes de la empresa tienden a presentarse en forma de datos.

Se analizan los datos de la empresa y los datos transaccionales para encontrar patrones
ocultos. Su fin es dar más recursos a los empleados para capta r clientes más
ef i cazmente , puesto que los conocen más: conocen lo que compran y cuándo lo
compran, y una serie de porqués más.
Este conocimiento se basa en hechos (datos) y experiencias, que pueden clasificarse en

2 categorías :
• No est ru ct ura dos. Datos que son consecuencia de la colaboración entre las <
z
<
u
personas : informes, presentaciones , " memoria " de la empresa , documentos o
a:¿
datos semi - estructurados como mapas de conocimiento. Son elementos que la o
gente utiliza para realizar trabajo c reati vo para el presente y para el futuro. ~
Organizar estos datos , hacer que estén disponibles y asegurar el acceso a los
mismos es de suma importancia para la capacidad de una empresa a la hora de "'a:
>
aprovechar con efectividad sus experiencias. z
::>
z
o
• Estructurados. Datos organizados en bases de datos que se pueden ana lizar de ü
<
o
z
cientos de maneras distintas para descubrir los patrones de compra de los clientes , ::>
LL
las dinámicas del mercado , el flujo de la cadena de suministros y, en definitiva,

cualqu ie r aspecto de la empresa . Conforme aumentan las conexiones entre las
personas, la can tidad de datos que generan y al que tienen acceso las empresas
crece dramáticamente. Más que nunca, es importante poder gestionar estos datos
de forma eficaz.
Cuando una empresa sabe ut iliza r eficazmente los datos no estructurados y

estructurados , es capaz de transmitir los beneficios de la experiencia a sus empleados ,
proveedores , d istribuidores y clientes. Esta co municación de los beneficios de la
experiencia es la mejor manera de asegurar cont inuas mejoras en el funcionamiento de
las empresas. Aprender se con v ierte en el resultado natural del proceso de
aprovechamiento .
244 DIRECCI Ó N Y GEST IÓ N DE PROY ECTO S TIC

__
EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACI Ó N PROYECTO E-BUSINESS
FUNIBERfj ........................................................
CASO: CHRYSLER SCORE
Chrysler ha aprendido a aprovechar el capital intelectual de sus proveedores de piezas y ha experimentado

una espectacular mejora de los beneficios como resultado. Mediante Lotus Notes, algunos enlaces de
conexión telefónica y unas cuantas aplicaciones sencillas, Chrysler está recortando costes de operatividad de
más de mil millones de dólares al año gracias a una comunicación directa y continua con sus principales
proveedores. Utilizando un sistema basado en Notes e Internet, los proveedores pueden comunicar
rápidamente ideas sobre cómo mejorar la fabricación de los componentes de automóviles.
El sistema que este fabricante de automóviles desarrolló se llama SCORE (Supplier Cost Reduction Efforf),
Esfuerzo de reducción de costes del proveedor).
Puesto que más del 70% de las piezas que se pueden encontrar en un automóvil de la marca Chrysler son de
proveedores externos, SCORE se implantó originalmente para mejorar las relaciones entre Chrysler y los
proveedores que le suministran toda clase de piezas: desde sub- ensamblajes a escobillas.
El programa pronto incorporó incentivos para motivar a los proveedores a sugerir productos que pudieran ser
útiles para reducir costes. Los Proveedores que sugerían una forma de ahorrar costes, no sólo obtenían el
negocio con Chrysler, sino que eran recompensados con una parte de los ahorros logrados.
<
:¡ El programa SCORE ha tenido tanto éxito que sólo 3 años después de iniciarse, Chrysler ha tenido que
u
a: actualizarlo para poder gestionar el volumen de usuarios y las ideas presentadas.
~
<
oa:
w
~ Chrysler ha transformado su relación con los proveedores. Juntos, el fabricante de automóviles y los
<
;;: proveedores, buscan constantemente cualquier pérdida en la cadena de valor añadido, identificándola,
<
¡¡; buscando su solución y compartiendo la mejora.
~
::
3 SCORE establece una relación de ganador a ganador, una forma de trabajar en colaboración con los
"'
o
ü
proveedores y demostrar que Chrysler se ha comprometido a verlos crecer.
o<
"'
::>
u..
Q
Para comprender un poco mejor la metodología e-Business expuesta en los apartados

anteriores, se desarrollará aquí el ejemplo del paso de la iniciativa e-Business a las
aplicaciones e-Business de una empresa seguros ficticia que se denominará XYZ.
4.6.1 LA ESTRATEGIA Y LA INICIATIVA E-BUSINESS
La compañía de seguros XYZ desea pasar de ser un negocio tradicional a un negocio e-

Business . Esto se origina con el siguiente objetivo de negocios: incrementar las
ganancias.
D IR ECCIÓ N Y GESTI ÓN DE PROYECTOS TIC 2 45

EJ EMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-BUSINESS
FUNIBER
Este objetivo de negocios se traduce en los objetiv os estratégicos de:
Incrementar ganancias y retornos por medio de explorar nuevos canales de

distribución de productos y servicios.
Bajar el ratio de gastos, manifestado por la relación entre los gastos totales y
los beneficios totales.
Mejorar tasa de retención de clientes mejorando el servicio.
Para satisfacer esos objetivos, XYZ asume que debe necesita una iniciativa e-Business
la cual necesita implementa r sistemas e-Business que provean:
Soluciones que permitan promocionar productos , analizar clientes potenciales,

y vender los productos a los clientes.
Aplicaciones orientadas al cliente (customer se/f service aplicaciones) que

permitan consultar planes o pólizas, consultar reclamaciones y capturar avisos
de daños, todo con el fin de ayuda r las llamadas que llegan al Cal/ Center y <
z
proveer un así un servicio one-stop a los clientes. <
u
a
Aplicaciones que ayuden a aumentar la velocidad de los procesos tales como la "<
o
creación de nuevos planes y el procesamiento de reclamaciones , por medio de "'

:;;
<
sistemas integrados y backend.
°'
,_<
::i
w
>
z
::>
4 .6.2 EL PLAN TÁCTICO z
·~
u
<
e
z
=>
u.
El plan táctico para implementar potenciales soluciones e-Business consis tirá de un
proyecto técnico de varias fases sometidas a objetivos que permitan a XYZ rápidamente
comenzar y desplegar funciones adicionales a las aplicaciones que surjan sobre Internet
en una ventana de tiempo de 6 a 8 meses .
El factor de éxito del proyecto e-Business será, en la dimensión gestión: el tiempo; y , en

la dimensión construcción: un desarrollo incremental eficaz que no entorpezca el paso
de un nivel de in cremento a otro. Para conseguirlo, se expone que el principio rector del
proyecto estará regido por el enfoque llamado time-boxed approach , un enfoque de
gestión y construcción modular contra el tiempo.
Este enfoque plantea que cada fase del proyecto a desarrollar tendrá como objetivo de
gestión el tiempo , es decir, cumplir los plazos (como un e-Project). Este c umpl imiento
de plazos exige qué, en caso que algún objetivo , una tecnología, aplicación o sistema e-
Business , o algún componente de negocio , no puede completarse en los términos
presupuestados y pactados para la fase, se rá transferido a la siguiente fase , aunque ello

FUNIBERt~
EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTAC IÓN PROYECTO E-BUS INE SS
. . . . . . . . . . . . . . . . . .mia. . . . . . . . . . . . . . . . . .- -
lleve el apremio del tiempo (en cierta medida aquí se asemeja al paradigma o ciclo de
vida en espiral).
Esto conlleva que la planificación de productos a conseguir (por ejemplo, a tra v és de un

WBS) en cada plazo debe ser incremental de tal manera que lo conseguido en una fase
sea la base para la siguiente (como un ciclo de vida en cascada).
Con este modus operandi, se pueden tener resultados en corto plazo , uniendo lo mejor
de va rio s paradigmas de desarrollo para el caso de un proyecto e-Business y, si el
proyecto se queda corto en tiempo , es decir, si algo falta cuando se alcance la fecha
límite del proyecto, los sistemas y las aplicaciones e-Business que existan estarán
funcionando a cabalidad.
Las soluciones e-Business serán arbitrariamente definidas como aquellas mostradas en

la , interface Web , seguridad , gestión de contenido , servicios de
colaboración e interfaces de transacciones y sistemas actuales (systems legacy) .
<
z
<
~ Las fases serán:
:::
"'<o
~ • Establecer presencia.
<
""'
<
t:
a:
• Proveer funciones de autoservicio al cliente.
~
:!
z
::l • Ampliación de las func iones de autoservicio al cliente.
z
·~
u
<
o
z
• Integración con las aplicaciones del negocio.
"
"-
Q
a.1 .- Fase 1 . Establecer presencia
Con esta primera fase se intenta que XYZ tenga presencia en Internet y defina su
arquitectura e-Business.
a.1 .1 .- Presencia en Internet
La fase pretende concluir en 3 -4 semanas con un conjunto de aplicaciones orientadas a

dar presencia a XYZ. Esta presencia se caracterizará por:
Aportar información básica sobre la compañía, sus productos y servicios a los

clientes; y,
Proveer información de contacto como direcciones posta les, números de

teléfono o cualquier otra que sirva para dar un mejor servicio al cliente , procesar
reclamaciones, etc.

E JEMPLO OE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E- B USINESS
FUNIBER
a . 1 .2. - Arquitectura básica
La fase ha de permitir a la compañía establecer los componentes arquitectónicos

básicos que ayudarán a dar soporte a las futuras aplicaciones e-Business.
Durante esta fase , la arquitectura tendrá los component es básicos que se necesiten
para crear y gestionar el contenido del web site. La arquitectura debe planificarse de tal
manera que en el futuro nuevas aplicaciones sean añadidas al web site.
Igualmente en esta fase se implementará una infraestructura de seguridad básica y un

plan de respaldo (backup) y recuperación (recovery) que asegure que la información y
las redes están a salvo de acciones o ataques intencionadas o no.
La muestra una arquitectura básica y las primeras aplicaciones e -Business.
<
z

z
::i
1r10
..,._"' ... """'°"'
~""
Servicios h abilitadores
z
~
..,
<
o
Po<MlnOI z
:::>
LL
...,,.,..
In';> ex
............... (~ º
lnfo. do Saluo.
CDnlaCtO
"""' Infraestructura de servicios
DftclDf10 5egunllod -
- os-
Figu ra 4 .20: Fase 1 del proyecto e-Business(3 -4 sernanas) 13 .
13 . IBM. Enlace web: _ yw ¡,.....,., con'

FU NI BE R ~ • • • • • •E•J•E•M•P•L•O•D•E•P•RO•Y•E•C•T•O•T•E•C•N•O•L•ó•G•1c•o•:•1M•P•L•A•N•T•Ac•1•ó•N-PR•O•Y•E•C•T•O•E•-•B•u•s•1N•E•s•s
b. 1.- Fase 2. Proveer funciones de autoservicio al cliente
Esta segunda fase del plan amplia funcionalidades y arquitectura conseguidas en la fase
previa ( ).
Servicios de aplicación
..
Servicios habilitadores
..
~
..,,,..,
..
~
--...
~
-
-
~
...
<
z
<
~
"'~
<
o
~
-
.._ ... ~
Infraestructura de servicios
~ o.cmno ~ -
:::
"'~
¡¡;
~
>
z
:::>
-os-
- ........
z
e
ü
<
o
z
:>
u. Figura 4.21: Fase 2 del proyecto e-Business (6-8 semanas) 14 .
º
b. 1 .1.- Ampliación de funcionalidades
Con esta fase se intenta construir la comunicación que permita al cliente lle ga r al
personal y los departamentos dentro de XYZ . Según esto , la fase implementa las
siguientes funcionalidades:
Capacidad para que representantes y agentes de servicio al cliente envíen y

reciban correo electrónico a sus clientes.
Inte gración telefónica que perm ita a los clientes programar encuentros con
agentes, y enviar mensajes y faxes a ind ividuos dentro de la organización.
14. IBM. Enlace web: w.vw 1r::irn.corri

FUNIBER ·~
E JEMPLO DE PROYECTO TECNOLÓGICO : IMPLANTACIÓN PROYECTO E-B USINESS
Autoservicio básico para que clientes y agentes:
generen órd enes y/o fo rmularios;
soliciten brochures y /o adquisiciones;
completen notas de Daños o Reclamaciones como parte del workf/ow de un

formulari o o plan; y/ o
localicen agentes y oficinas de reclamos usando un GIS (Geographica/

lnformation System).
b. 1 .2.- Ampliación de arquitectura
La arquitectura es extendida con servicios de co laboración que incluyen gestores de

co rre o, gestor de workflow, serv icios de te lefonía (fax, por ejemplo ) y otros servicios de
workgroup tales como gesto res de calendar io y programación de tareas (scheduling).
<
z
c.1 .- Fase 3. Ampliación de las funciones de autoservicio al cliente 
z
:::>
z
·~
u
<
o
z
--
::>
servidos de aplicación u.
,...,
__ ,
"'
-
-
. .. ·- ........., """"" -. ...
. -.. ...........
servidos habilitadores
.... - .......--- -·
.,..,..- ...._ '-"'
"' ......., """"'"""
~
,
-·-__ .._ º"''" c.r...
........
.........- --~
~- = -~ /
..... - -
Cliltm
----~
- - .-
,
,_... ... e.n..e.
....,.. Infraestructura de servid os )
°"""""' - -
Gdmr'dt-~dif~
1
=::- ----- 1
Figura 4 .22: Fase 3 del proyecto e-Business(B-12 semanas) 15 .
15. IBM. Enlace web: 1w1w.ib~ com
250 D IRECCIÓ N Y GESTIÓ N DE PROYECTOS TIC

EJEMPLO DE PROYECTO T ECNOLÓGICO: IMPLANTACIÓN PROYECTO E- B US INESS
Debe añadirse que fases 2 y 3 pueden haber tantas como incrementos se permita el
proyecto dado el volumen de aplicacio nes que se proyecte in icialmente.
c .1 .1 .- Ampliación de funcionalidades
A nivel de funcionalidades ahora busca permitir que lo s clientes realicen consultas en

los pl anes de su portafolio de cliente. Con esto se pued e chequea r el estados de las
reclamaciones que puedan tener abiertas y el estado de sus reclamacio n es que hayan
iniciado.
Visto así, la fase busca la implementación de las siguientes funcio nalidades:
• Búsqueda de clientes y consulta de portafol io .
• Consu lta de planes .
• Consu lta de reclamaciones.

<
z
<
~
• Consulta de pagos .
"'
w
"
<
o
::; c.1.2.- Ampliación de arquitectura
.'!!
<
;;:
<
1-
;;; La arquitectura se amplia con servicios de conecti vidad backend que incluyan gest or de
~
> cola de mensajes y conectores dentro de l sistema backend como gateways Web-CICS ,
%
=>
Web-IM S, SOL server web conecctore , Net.Data y otros co nectores backend.
5
u
<
o
; d.1.- Fase 4. Integración con las aplicaciones del negocio
u.
©
Similar a la fase previa, esta fase amplia las funciona lidades de autoservicio del clien t e y
la arquitectura resul t ante de la fa se previa ( ), pero con la salvedad que ahora
busca consolidar procesos críticos del negocio e integrar sistemas y aplicaciones e-
Business con la realidad actual de sistemas de XYZ.

E JEMPLO D E PROYECTO TECNOLÓGICO : IM PLA NT ACIÓ N PROYECTO E-B USI NES S
FUNIBER
Setvldos de apliadón
~CD«lcll'~·~ - - - - --+
- ......... ........
-.... --
"""-'="
.. '"""'"'
- -· -·- .... ......
Servidos habilitadores
""
"""""""" .__.
.... ..
-- - --- ...._. _.,,
°'""'"·
.........
c.-
--- ---
,,...,.._ ........ _.,
_____ /
.. _ _
_.
°"""
...
- ......._
"""' """" """""""
""""'·<I041r '""""'
...
'-
lnfraestnlCb.ora de servidos
~
__...
-a¡- J
<
z
Figura 4 .23: Fase 4 del proyecto e-Business (12-16 semanas) 16. <
v
E
"'<o
d . 1 .1.- Ampliación de funcionalidades ~
<
o:
~
La cuart a fase añade funciones críti cas t al es como procesamiento de planes y "'~
>
procesamiento de r eclamaciones . Para esto , las funciona l idades que se pe r siguen z
::>
z
alcanzar aho ra son: -O
'-
<
o
z
::>
Capturar nuevos negocios a través de Intern et. u..
Procesar planes (endorsar planes, cambiar direcciones de pagos , añadir c riterios

a los planes, etc.).
Procesar reclamaciones (entrar avisos de daños y se r capaz de hacerles un

seguimiento al reclamo hasta que es sat isfecho o atendido).
Mod if icar opciones de pago de los planes .
d.1.2. - Ampliación de arquitectura
La arquitectura se ampl ia de tal mane ra que se añadan servici o s habilitadores que

incluyan eleme ntos como , p o r ejemp lo, el Object Request Broker de CORBA el cual
cont ien e el Componen Br oker y un Monitor de T ransacciones (C ICS o ENCIN A) .
I gualmente se añaden cone c tores dent ro de los s i stemas backend tales como
16. IBM. Enlace web : , •, .\ .om co-,
252 D IRECCIÓ N Y GESTI ON DE PROYECTOS T IC

FUNIBERÍ'~ ........................................................ --
E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E-B USINESS
Cbconnector , Java - CIS gateway y / o Java-MO gateway que permitan ac c eso

transaccional a las aplicaciones backend.
4.6.3 COROLARIO
Independiente de las tecnologías usadas y su complejidad intrínseca, el proyecto tiene la

complejidad de asumir que se está ante una pirámide de la cual sabemos perfectamente
lo que tiene que ir en cada nivel para así tener las bases del n ivel superior. Lo
interesante es que esto exige saber cuales funcionalidades y servicios de la arqu itectura
deben ir primero , no obstante si esto se sabe al inicio del proyecto es posible una
plan ific ación, en caso contra r io hay que asumir los riesgos de fallar y elabora r una
planificación por contingencia .
<
z
:
<
*
<
;;;
A continuación se presentan algunas soluciones e-Business implementadas en algunos
< negocios:
¡¡;
~
::z
::::>
z
a.- Autocares Jiménez - Integración de aplicaciones
2
u
<
o • Necesidad del Cliente : Venta de Billetes para agencias a través de Internet .
z
"
"-
• Objetivo : Permitir a las agenc ias de viaje la compra de billetes desde Internet
mediante pago po r tarjeta de crédito (los tipos dependen del proveedor de la
pasa rela de pago) o con facturación posterior.
- Permitir a los usuarios particul ares la compra de billetes desde Internet mediante
pago por tarjeta de crédito.
- El pro ceso de adquisición de un billete de Autobús se rá completo pudiendo

esco ger el usuario la pl aza donde desea viaja r dentro del autobús .
a. 1 .- Soluciones desa rrolladas por iA Soft
Funcional
a.1 . 1 .- PASO O: Entrar en la aplicación.
- Se permite la entrada a la aplicación a cualquier usuario registrado o no.
D IRECCIÓN Y GESTION DE PROYECTOS TIC 253

FUNIBER~
E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTA CIÓ N PROYECTO E- B USINESS
En el caso de usuario no registrado pasará di rectamente al paso y

automáticamente se le propone utilizar la ayuda para realizar la compra.
En el caso de ser un usuario registrado deberá introducir su nombre de usuario y

su contraseña, que será verificada , para poder acceder al siguiente paso. De
esta forma apa recerán seleccionadas las características de último trayecto para
el que compró billetes excepto las fechas de ida y vuel ta.
- Las agencias se valida rán mediante un nombre de usuario y una contraseña que
defin irá el tipo de operaciones que podrá realizar .
Nota: No es lo mismo un usuario de internet registrado que una agencia aunque tengan
el mismo punto de entrada.
Las operaciones que puede realizar una agencia son:
1. Comprar pagando con tarjeta de crédito.
2. Comprar con pago posterior. Con límite de crédito.
3 . Ambas operaciones.
Este punto está paremetrizado así: (desde la aplicación de gestión).
• Definición de agencias.
• T ipos de operaciones permitidas para las agencias.
• Crédito disponible de una agencia.
• Usuarios de las agencias.
• Mantenimiento de los usuarios de internet que se han registrado .
• Consulta de las operaciones realizadas por los usuarios.
a.1 . 2 .- PASO 1 : Selección de trayecto .
El usuario debe seleccionar el origen, el destino , el número de billetes , el tipo de

descuento que desee aplicar, el tipo de vuelta y la fecha de ida y de vue lta en el
caso que corresponda.
Los orígenes y destinos serán todos los dispon ibles en los que pueda existir un
servicio válido. Además aparecerán todas las posibles combinaciones posibles
de itinerarios para viajar del origen al destino de forma transp arente al usuario.
La fecha máxima de venta tiene un rango de val idez que se aplica a la ida de
forma natural y a la vuel ta en función de la fecha de ida.
254 D IRECCIÓN Y GESTIÓN DE PROY ECTOS TIC

FUNIBER f~ --------------¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡=::;
E J EM PLO DE PROYECT O TE CNOLÓGICO: IMPLANTACIÓN PROYECTO E-B USINESS
Los descuentos se aplican a todos los billetes que se compran . Es decir, no se

pueden combinar desc u ent os. Un aviso al u sua r io es mostrado cuando se
produce ést a situació n .
a.1.3.- PASO 2 : Selección de horarios.
El usua ri o de be se lecci onar un a ho ra de ida y o t ra ho ra de vuelta en el caso que

corresponda.
El objetivo de selección es dar al usuario el mayor abanico posible de horas de

salida p ara desplazarse un OR IGEN a un D EST INO.
No se selecc ionarán se rv icios . Sólo se mostraran ex pediciones.
a .1.4.- PASO 3 : Selección de plazas.
El usua rio selecciona las plazas que desea en cada uno de los autobuses en los
<
z que deba viajar .
<
u
..,"'
:r
<
Se hace notar al usu ario que las plazas que selecciona podrán ser cambiadas de
o
"'w posición si n previo aviso . Esto es debido t anto a los posib les traspasos de plazas
"'
<
« como a las colisiones producidas po r la compra mediante ta rjeta.
<
Dependiendo del las propiedades del tipo de usuario que está rea lizando la
comp ra es posible no notificar que las plazas han colisionado y asigna r le
automáticamente otras. Esta opción puede ser inte resant e para las agencias de
v iaje , pero po r defecto está desactivada.
Una vez seleccionadas las plazas se procede a la fase de compra.
a . 1 .5 .- PASO 4 : Fase de compra .
La fase compra se compone de:
Introducción de datos del comprador . Si el usuario es registrado se le da la

opción de modifica rlos si lo cree conveniente . Si no es usuario registrado se le
piden ob ligatoriamente el nombre , primer apellido , cédula de identidad y
dirección de correo electrónico. Además se le propone hacerse usuario
registrado. También se le da acceso a leer la información sob re la Ley de
Protección de Datos .
Lectura de condiciones de compra , resumen de compra y tipo de pago . El

usuario debe aceptar las condiciones que aparecen en la pantalla para poder
realizar el pago. Los tipos de pago se muestran en función del tipo de usua r io ;
si el usuario es una agencia o un usuario normal de internet. A los dos tipos de
usuario se les ofrece paga r con tarjeta de crédito . En el caso de usuar io de
DIRECCIÓN Y GESTION DE PROYECTOS TI C 255

EJE MPLO DE PROYECTO T ECNOLÓGICO: IMP LANTACIÓN PROYECTO E- BUSI NESS
FUNIBER
agencia se le permite en pago con cargo en el caso de que tenga crédito mayor
de cero. Si el crédito no es suficiente se le notificará.
En el caso de que el usuario selecc ione comprar con tarjeta de créd ito se pasará
el control a la pasarela de pago de la entidad banca ria para formalizar el pago.
En el caso de pago con cargo esta ope ración no es necesaria .
Visualización del bil lete comprado e impresión del mismo.
Se insta al usuario a imprimir su billete.
Si el usuario ha especificado una dirección de correo válida se le enviará la

información de la compr a a dicha dirección.
b.- GIR (Gestión Integral en Red) - Integración de aplicaciones
• Necesidad del Cliente. La Consejería de Edu cación del Gobiern o de Aragón , con la
intención de optimizar las labores de gestión de los centros de enseñanza y agilizar
las relacio nes que estos mantienen con el departamento, se propone llevar a cabo
<
el desarrollo y la implantación de un sistema informático que permita la Gestión z
:
<
o
El sistema , h aciendo uso de tecno lo gías web, can alizará y centraliza rá todos los ~
flujos de información generados , independientemente de su ubicación física. De ='«
~
este modo , se convertirá en una potente herramienta de control que, entre otras "'"'
~
>
prestaciones , ofrecerá un apoyo inestimable a los procesos de toma de z
::>
z
decisiones . -e
ü
<
o
• Los principales objetivos son : ...z

:>
Centralización de Datos . Todos los datos utilizados y /o generados por los

centros de enseñanza del sistema educativ o en el transcurso de su actividad
habitual se centra lizarán en un único Sistema Informático accesible de forma
remota.
- Aplicativos Remotos . Para operar sobre este sistema se desarrollarán una serie
de aplicativos remotos que ofrezcan el servicio adecuad o a todos los posibles
usuarios del sistema (centros de enseñanza, personal del departamento, padres ,
alumnos, etc ... ).
Control de Acceso . Todos los aplicativos remotos desarrollados implementarán

un control de acceso , basado en perf iles de usuario , de gran v ersatil idad que
delimitará la capacidad del usuario tanto en consulta como en edición de datos o
ejecución de procesos.

EJ EMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E- BUSIN ESS
FUNIBERff
------------------------------------
b. 1 .- Soluciones desarrolladas por iA Sott
Funcional
La arquitectura de software propuesta para el Sistema Informático GIR se corresponde

con un modelo de tres capas que responde a la siguientes características:
Cada módulo funcional básico provee las funciones de gestión y operación

básicas correspondientes a su repositorio de datos asociado , pudiéndose
considerar cada par módulo - repositorio una aplicación independiente.
La arquitectura implementará los interfaces necesarios para permiti r articular

rela ciones entre los distintos repositorios de datos.
Cada aplicación (por módulo - repositorio ), si bien dispondrá de un conjunto de

datos y funciones genéricos de partida , se diseñará de forma que pueda ir
creciendo en función de las necesidades que planteen los aplicativos remotos .
<
z
<
~ Los aplicativos remotos se definen como clientes ligeramente pesados y a que
::>:
< incluyen la lógica de integración necesaria para conjugar y aprovechar todos los
5.. servicios que ofrecen los módulos f uncionales básicos .
::
"'<
.... En el Diagrama Operativo se hace especial mención, dentro de los repositorios
~
> " Personal Centros " y " Centros ", de los apartados " Profesores " y " Plan
z
:::>
z Académico" ; el motivo es la especial importancia que estos apartados tienen
-o
ü para el funcionamiento habitual de los centros de enseñanza.
<
o
z
::>
....
Basada en esta arquitectura se desarrollarán :
- Aplicativos para los centros de enseñanza (Proceso de admisión , matriculación ,

gestión adm inistrativa ... ).
Aplicativos de información y reporting (acceso de carácter consultivo a toda la

información de los centros de Enseñanza).
- Aplicativos de Padres y Alumnos a través de Internet a los diferentes procesos

(admisión, matriculación, consulta horarios, faltas , calificaciones .... ).
c.- SIRASA - Sistemas de gestión

• Necesidad del Client e . La Sociedad de Infraestructuras Rurales Aragonesas
(SIRASA ) es una empresa públ ica que se encarga de adjudicar y gestionar los
proyectos in ic iados o subvencionados por los departamentos de Agricultura y
Medio Ambiente de la Diputación General de Aragón. El cliente nos transmite la
necesidad de disponer de una aplicación para gestionar los proyectos en los que se

encuentra involucrada, desde el momento de su notificación hasta el cierre de los

mismos pasando por la licitación , seguimiento y certificación.
En el momento de plantearnos esta necesidad, el cliente dispone de una aplicación
de contabilidad, una aplicación de gestión de nóminas en COBOL y una aplicación
de Access de gestión de expedientes desarrollada por una persona del
departamento jurídico de SIRASA con la que se gestionan cerca de 1 80 proyectos.
Las dos primeras aplicaciones cumplen su labor pe ro la Gestión de Expedientes solo
mantiene registro de datos y fe chas relevantes de cada proyecto. La apl icación de
expedientes de Access presenta muchas limitaciones principalmente por las
dificultades que plantea de cara a trabajar en red y porque se espera de ella un
apoyo a la hora de gestionar los expedientes (alarmas y reg las de validación) y los
proyectos (generación automática de documentos, sobre todo certificacio nes ) que
actualmente no ofrece.
El cliente requiere una aplicación capaz de funcionar en red local soportando un

mínimo de 12 usuarios simultáneos. La aplicación debe permitir a las delegaciones
<
z
en Huesca y Teruel el acceso al servidor situado en Zaragoza. Se debe garantizar la <
u
~
viabilidad en base a diversas alternativas (acceso telefónico a redes , VPN , etc.) , <
o
a:
principalmente para consu ltaras. w
"'
Para cubrir las necesidades presentadas por el cliente , es necesario que la aplicación
controle lo siguiente:
Control completo de procesos según los tipos de expedientes con cada una de
sus fases:
Recepción de documentación de la DGA (ape rtura del expediente).
Anteproyecto (pliego, plano , presupuesto y memoria técnica) y estudio de

impacto medioambiental si procede.
Licitación y, en su caso, aprobación.
Ejecución , desde el acta de replanteo hasta la de recepción , pasando po r las

sucesivas emi siones de certificaciones y registro de facturas en diversas
anualidades.
En todas las fases del expediente, se debe gestionar el control económico

de estado del expediente y de hitos temporales.
Se debe inclu ir la capacidad de control documental permitiendo adjuntar

documentos a cada expediente .
Para cada tipo de expediente se incluirán una serie de validaciones y alertas

que permitirán controlar incoherencias (sobre todo temporales) y datos
necesarios / opcionales en la gestión del proyecto (por ejemplo: una alerta
avisando de que se ha procedido a la adjudicación del proyecto sin aportar la

EJ EMPLO DE PROY ECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E- BUSIN ESS
FUNIBER
fecha concreta o las emp resas participantes ). Deben ser solo avisos (en
forma de lag de alertas) y no impedi r el curso normal de t rabajo.
Según las necesidades aportadas por el cliente, se prevé la inclusión de nuevas

funcionalidades en un futuro:
Display gráfico del estado del proyecto en forma de workflow que muestre
según códigos de colores el estado de tramitación del expediente: f ases
superados, fases incomp letas con datos sin concretar y fases pendientes.
Valoració n de índices para controlar la calidad total en la gestión del trabajo

diario de la empresa . Índ ices tipo: tiempos medios desde la c reación del
expediente hasta su publicación , desde publicación hasta su adjudicación , etc .
Sistema de control de costes interno (ho ras por proyecto de los responsables ).
c.1 .- Solu ciones desarrolladas por iA Soft
<
z
Funcional
<
u
a:
"<
o
Estudiadas las necesidades del cliente, iA Soft propone un sistema c li ente-servidor que
..
e;
funcione en red y sirva de sistema de Gestión de Expedientes y Contro l económ ico y
documental.
Para la Gestión de Expedientes y Control Económico, en SIRANet se re fleja la principal

z
-o actividad de SIRASA: gestionar encargos de dos departamentos de la DGA
u
<
e (Departamento de Medio Ambiente y Departamento de Agricultura ). A cada uno de
...5 estos encargos , se les dará de alta , as ignándoles un número de exped ie nte para
identificarlo . Cada encargo lle v a asociado un procedimiento más o menos exte nso
según la tipología de los mismos. Todo el trabajo de SIRASA gira entorno de estos
expedientes , por esto han de estar perfectamente ident ificados , expresando el mayor
número de características de los mismos , en cuanto a responsables , pro vi ncia ,
comarca , etc.
De manera simplificada , el flujo normal de los expedientes , aunque para cada tipo varíen
algunos factores según se entra en detalle y se incrementa la complejidad de los
m ismos, es el siguiente:
• Comunicación de proyecto / subvención desde DGA.
• Apertura y tramitación del expediente.
• Si procede , estudio de impacto medioambiental.
• Anteproyecto (pliego, presupuesto, plano , memoria técnica, etc. )
• Licitación.

EJEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E- B USIN ESS
FUNIBER
• Ejecución (dirección facultativa, codrdinación de seguridad y salud).
• Certificaciones mensuales.
Se ha considerado fundamental mantene r la información estática que se gestionaba en

la aplicación Access del cliente. A esto se le han añadido una serie de validaciones en la
edición de los expedientes, una mejoría en la gestión de plazos , gestión de proyectos y
generac ión de doc u m entos . Alguna de la información estática del expediente es la
siguiente:
• Estado del expediente (abierto , en ejecución, cerrado, etc. ).
• Fechas relevantes de cambios de estados.
• Fechas y costes de publicación en 80 y prensa.
• Responsable del proyecto.
• Datos del Anteproyecto (responsable y coste).
• Presupuesto del proyecto.
• Plazos.
• Anualidades.
• Empresas participantes en la licitación. z

<>
• Empresa adjudicata ria . "'<e

z
::>
u..
~'
• Baja (porcentaje de descuento con el que se ha adjudicado el proyecto respecto al
presupuesto de partida).
• Información de los datos detallados de elementos presupuestados incluyendo

cantidad y precio unitario.
Para el Control Document al , la aplicación gene ra automát icamente y guarda el mayor

número de documentos posibles. En aquellos casos en los que esto no sea posible o
recomendable por razones operativas , se da la posibil idad de adjuntar un documento
externo de una manera opcional. Algunos documentos relacionados con la aplicación
son:
• Pliego de cláusulas administrativ as.
• Información de solicitud.
• Aprobación del expediente.
• Orden del consejero.

E J EMPLO DE PRO YECTO TECNOLÓ GICO: IM PLA NTAC I Ó N PROYECTO E-B USINESS
• Fiscal ización .
• Acta de apertura.
• Informe de licitación.
• Propuesta de Adjudicación .
• Aprobación de la Adjudicación.
• Aval (en el caso de subvenciones parciales) .
• Convenio.
• Certificados.
• Comunicaciones de SIRASA.
• Acta de rep lanteo (comienzo de obras).
< • Acta de recepció n (final de obras).

z
<
u
;;:
~ • A visos prev ios.
<
o
"'
~
"' • Certificaciones.
• Liquidación .
• Contrato.
Una de las labores mecánicas y laboriosas que se ha resulto con el desarrollo de la

aplicación SIRANet es la elaboración de certificaciones , que deben rea lizarse
mensualmente. A su vez, se ha desarrollado un sistema de seguimiento de éstas.
Esta documentación de certificación del proyecto (carátula , relación valorada y factura)

se elabora automáticamente a partir de la introducc ión de elementos en producción,
ce rt ificados y facturas a DGA que se lleva a cabo mes a mes y de la información de
meses anteriores.
En el seguimiento de proyectos , se incluye la gestión de formas de pago a contratistas ,

directores y coordinadores de segu ridad y salud que puede ser prorrogada a lo largo del
plazo del proyecto, en función de las certificaciones , de l progreso del proyecto o
gestionada de manera manual. En este último caso se plantea una val idación evidente:
la suma de cant idad introducidas manualmente nunca debe superar la cantidad total
estimada para el proyecto.
La aplicación también ofrece informes agrupados por gestor, tipo de proyecto, empresa
proveedora o cliente final (diversos departamentos de DGA , comunidades de regantes ,
DIRECCIÓN Y GEST ION DE PROY ECT OS TIC 261

E JEMPLO DE PRO YECTO TECNOLÓGICO : IMPLANTACI ÓN PROYECT O E-B USINESS
entes o personas subvencionadas) que muestran básicamente el import e del proyecto ,

el impo rte de la adj u dicación teniendo en cuenta la baja , la cantidad ce rtificada , la
cantidad r esultante de las obras ejecutadas, la cantidad facturada , fechas , plazos ,
totales y medias temporales. Es posible obtene r el est ado del proyecto.
Ot ros aspectos que se han tenido en cuenta en el desarrollo de SIRANet son:
• Se mantiene la info rmación rela t iva a proveedores y clientes.
• Agrupación de datos económicos por anualidades para poder presentar la

información totalizada y anualizada.
• Creación de Gestión de Históricos puesto que la información de expedientes

cerrados de años anteriores no parece relevante para el trabajo diario.
d.- Col-Ven
Col-Ven S.A es una empresa Argentina , ubicada en Gu adalupe , Santa Fe , que desde <
z
hace más de 26 años se ca r acteriza por brindar Soluciones innovadoras al mercado :
<
o
transpo rte de cargas y pasajeros, vehículos pa rticu lares, etc., en busca de seguridad y ::;
"'
confort para los elementos mecánicos, y las marcas VIGIA y VIESA están <
"<
definitivamente incorporadas en el mercado. ;¡;
~
>
17 z
::::>
Luego de una primera experiencia en Internet con su s1t10 institucional , la empresa z
-o
decidió re-definir sus objetivos en Internet, y los recursos para log rarlo. ü
<
o
z
::>
u.
,....
El desafío
Comenta Lorena Vénica , Responsab le de Implementación del Sitio Web de Col -Ven
S.A .:
"Nuest r a empresa ha desarrollado mercados en el exterior , y por ello tenemos una

necesidad muy conc r eta de comunicación con los mismos. Actualmente tenemos
agentes en América , Europa y Oceanía y debemos proveerles información persona lizada
a cada uno de ellos " .
Requ erimientos del Portal Corporativo Col-Ven
"Luego de nuestros primeros pasos por Internet , decidimos replantear nuestra

presencia. Entonces definimos los requerimientos que nuestro nuevo s it io debería
cumplir:
17. Enlace web: ~tto: wv.w co1ve1.ccrr.ar
26 2 DIR ECCIÓN Y GESTIÓN DE PROYECTOS TIC

EJEM PLO DE PROYECTO TECNOLÓGICO : IMPLANTACIÓN PROYECTO E-BUSINESS
• Permitir al personal de Marketing generar y publicar contenidos, sin necesidad de

conversión a HTML po r el Area de Aistemas .
• Filtrar contenidos según el cliente que accediese al sitio .
• Entregar contenidos a usuarios específicos.
• Poder "trackear" a nuestros visitantes para conocer mejor sus intereses".
La idea fuerza era que el área comercial tuviese "el control" del s itio, que pudiese
publicar información cuando quisiera, dirigida a quienes quisieran, de una forma veloz y
sencilla, y por otra parte poder analizar el comportamiento de los clientes.
Luego de recibir varias propuestas, Col-Ven se decidió por utilizar la tecnología IMS ,
desarroll ada por EXO , para administrar los contenidos a publicar en Internet y Extranet.
" La propuesta de EXO nos pareció novedosa, absolutamente compatible con los
objet ivos que perseguíamos" .
z<
<
u
o:
~ El desarrollo del Proyecto
<
~
w
"' El sitio de Col-Ven fue desarrollado sobre la vers ió n Corporate Hosting de IM S, la cua l
<
o:<
t: corre sobre un Servidor IMS ubicado en las oficinas de EXO. Ello posibi l ita realizar
"'~
~ recortes de costos de hardware, software y comunicaciones. La administración de los
z
:::J
z contenidos es realizada en forma remota por los usuarios no t écnicos, generadores de
·O
u
<
o
contenidos.
z
::>
u.
Próximamente está prevista la puesta en producción del módulo multilenguaje, el cual

permite publicar informac ión en ilimitados lenguajes manteniendo la relación de los
documentos para el caso de modificación o baja .
Ficha Técnica :
• Cliente : Col-Ven S.A.
• Proyecto: Portal Corporativo Col-Ven.
• Solución : IMS Corporate Hosting.
• Implementación: 5-2000.
e.- Ericsson estrena su portal corporativo desarrollado por EXO
EXO desarrolló para Ericsson SACI un sofisticado portal co rpo rati v o para entregar
información dirigida a cada uno de sus clientes. Basado en IM S -el sistema de
administ ración de contenidos desarrollado por EXO- incluye características av anzadas ,

E JEMPLO D E PROYECTO TECNOLÓGICO : IMPLA NTACIÓN PROY ECTO E-B USINESS
FUNIBERff
tales como personalización y filtrado de contenidos, Business lntelligence, Marketing

One to One y generación distribuida de contenidos.
Eduardo Griffa , Responsable de Marketing & Soluciones de Compañía ERICSSON SACI ,

nos brinda un panorama de las características del proyecto:
¿Cuáles fueron las causas que impulsaron a Ericsson a desarrollar el portal

corporativo local?
En principio una urgencia de mejorar la comunicación externa y

fundamentalmente con nuestros clientes. El portal local es una herramienta de
relación con nuestros clientes que el portal corporativo de ERICSSON no llega a
brindar.
¿Cómo se integra el portal corporativo en la estrategia comunicacional de Ericsson?
Es una pieza fundamental en este "New Telecoms World" para un marketing

personalizado a cada necesidad.
<
z
¿Cuáles fueron los requerimientos técnicos que la Solución debería satisfacer? <
~
"'
:r
Los requerimientos eran: disponibi lidad inmediata, fácil administración (no <
o
queremos tener expertos en html!) y customización doble: cada cuenta debería ~
<
tener su site particu lar y cada cliente la posibilidad de personalizar su portal de ;;;
<
>-
Ericsson.
5>
z
¿Qué aspectos tuvieron en cuenta al momento de seleccionar a EXO para el :::>
z
desarrollo del portal corporativo? ·~
"'<o
z
La selección de EXO surgió como proveedor confiable con una solución que "'"
satisfacía nuestros requerimientos.
¿Cómo evalúa la interacción del personal de Ericsson y EXO durante el proceso de

desarrollo e implementación de la Solución ?
Profesional y correcta.
¿Cómo imagina la evolución del portal corporativo de Ericsson Argentina?
Lo imagino como un sitio preferentemente para clientes y un sitio de referencia

en cuanto a Tecnología , y de a poco iremos abriendo nuestra Intranet , que es
una de las más grandes del mundo.
Ficha técnica :
• Cliente : Ericsson SACI.
• Proyecto: Portal Corpo rativ o.
• Solución: IMS.

E JEMPLO DE PROYECTO TECNOLÓGICO: IMPLANTACIÓN PROYECTO E- B USINESS
• Características :
Generación de contenidos distribuida entre 25 usuarios no técnicos

pertenecientes a las distintas Unidades de Negocios .
Sitios pe rsonalizados en estética y contenidos para cada c liente corporat ivo.
- Business lntelligence. Análisis del comportamiento de visitantes.

- Accediendo a una base de datos Oracle 8.05.
Personalización de contenidos por el visitante.
Filtrado de contenidos a determinados grupos de usuarios.
• Implementación : 5-2000.
f.- Trading Argentina lleva sus negocios a internet
TR ADING ARGENTINA es una compañía especia lizada en Comercio Internaciona l y

Consultoría de Empresas , con una t rayecto ria de más de 40 años prestando servic ios a
algunas de las más prest igiosas empresas del país.
:::
"'<t La necesidad de compartir inform ación con c lie ntes, prospect os y proveedores de una
"'"'u forma personalizada a través de la Web los o r ientó hacia IMS, el s i stema de
>
z
::> administ ración de contenidos Internet desarrollado por EXO.
z
·O
ü
<
o
z Alejandro Jausoro, Gerente General de Trad ing Argentina , comenta las características y
:>
u.
alcance del proyecto.
1. ¿Cuál es la actividad principal de Trading Argentina?
Trading A r gentina es una compa ñía especializada en Comerc io Internacional y en

Consultoría de Empresas .
Lle vamos muchos años t r abajando con industrias de produ cto s de consumo masivo,
abasteciéndolas de materias primas de prime ra calidad.
Esto nos ha permitido desarrollar fuertes vínculos con la i ndus t ria y conoce r
personalmente las fáb ricas , las capacidades y calidad de cada una de ellas.
Trading Argentina , es representante de emp resas principa lme nte de: Chile, Pe rú, Brasi l,
Ecuador , Uruguay, Bolivia, USA, Canadá , Tailandia, España y Francia.
También somos Agente de Compra de algunas empresas del exter ior que confían su
abastecimiento en nuestra compañía.

E JEM PLO DE PROYECTO T ECNOLÓGI CO : IMPLANTAC IÓN PROYECTO E-B USINESS
2. ¿Qué causas los impulsaron a desarrollar el site?
Nuestros proveedores están distribuidos en todo el mundo y nuestros clientes no se

limitan al territorio de Argentina, sino que abastecemos clientes en distintos países.
En definitiva nuestro negocio es global , por lo que el uso de una herramienta global
como lo es internet, es imprescindible para el logro de nuestros objetivos.
3 . ¿Cuáles eran los requerimientos que el desarrollo debía satisfa cer?
Desde un principio nos fijamos las siguientes premisas para construir nuestro site:
Diná mico y de actu alizaci ón p erm ane nte por el propio perso nal de Trading , sin
necesidad de recurrir a un desarrollador de páginas html.
Con contenidos técnicos que interesaran a nuestros clientes y proveedores.
Amigable para el visitante y fácil de navegar.

<
z
<
u
Escalable en contenidos y funcionalidad. §
"'<o
«
Versiones en español e inglés. ~
"'
Trading Argentina está formado por un grupo hu mano interdisciplinario de profesionales

con distintas extracciones , y todos ellos necesit an aportar contenidos al sitio. La idea
era que lo pudiesen hacer directamente, sin poseer conocimientos de programación
web .
4 . ¿Cómo planea integrar sus actividades en la web con proveedores y clientes?
Respecto a los proveedores, en el sitio tiene un detalle pormenorizado de sus productos.
En una próxima etapa v amos a dar información extensiva de cada uno de el los.
Con relación a los clientes , cada uno de ellos tendrá acceso a informac ión espe c ífica ,
como el seguimiento de los contratos que ellos tienen con nosotros, tiempos y logísti ca
de entrega , modificaciones, etc. , como así también a los futuros negocios a realiz arse.
5. ¿Qué aspectos tuvieron en cuenta al contratar el desarrollo a EXO?
La premisa básica fue contar con una aplicación poderosa , que permitiera tener un site
ilimitado en cuanto a expansión , de fácil mantenimiento , y amigable . Buscábamos no
depender de un agente externo para el mantenimie n to de l site para actualizarlo
diariamente desde nu estra empresa.
266 D IRE CCIÓN Y GESTIÓN DE PROYECTOS TI C

FUNIBERf~
EJEMPLO DE PROYECTO TECNOLÓG ICO : IMPLANTACIÓN PROYECTO E-BUSINESS
. . . . ._ .. . . . . . . . . .11:m. . . . . . . . . . . . . . . . . . . . . .- -
Eso fue lo que encontramos en EXO , que no nos ofrecieron otros pro v eedores de
Soluciones Internet.
Además encontra mos una empatía muy fuerte con el equipo de EXO , que nos f acil itó la
decisión.
Por otra pa rte, si se analiza la inversión necesaria en función de la información

publicada , la cantidad de páginas generada y el ahorro que surge de la no uti lización de
medios de comu nicac ión tradicionales , el cost o por pág in a resulta casi irre lev ante.
6. ¿Cómo evalúa la inte rac ción del personal de Trading y de EXO?
Ex c elen t e, se trabajó como un solo equipo entre lo s mie mb ros d e EXO y nu estro
personal.
Estamos plenamente satisfechos con los resultados obtenidos .

<
z
<
~ Ficha técnica :
">'.
<
o
~ • Cliente: Trading Argentina.
"'
• Proyecto : Portal corporativo Trading.
• Solución : IMS Corporate Hosting (http: ims.exo .com .ar) .
• Implementación: 8-2000 .
D IRECCIÓN Y GESTIÓ N DE PROYECTOS TIC 267

FUNIBER~
EJ EMPLO DE PROYECTO TECNOLÓGICO: IMPLANTAC I ÓN PROYECTO E-B USINESS
_ _ _ _ _ _ _ _ _ _ _ _smc_ _ _ _ _ _ _ _ _ _ _ __ _
OResumen
<
"'<
!::
~
u
~
z
=>
z
·O
ü
<
o
z
"
"-

H ERRAMIENTAS Y TÉCN I CAS DE GEST IÓN DE PROYECTOS
HERRAMIENTAS
, Y ,
z<

z
~
•!:
u
<
o
z
:>
u..
Q
- Conocer algunas de las principales herramientas y técnicas empleadas en la gestión de proyectos.
Para completar este capítulo de gestión de proyectos para un proyecto tecnológico no

se deben olvidar una serie de herramientas y técnicas de gestión. Estas herramientas y
técnicas se presentan a continuació n vincu ladas los grupos de procesos, lo c ual no
significa que ellas sólo sean de aplicabilidad a un solo grupo. Igualmente , muchas de
ellas se encuentra soportadas por diversas herramientas informáticas . (ver Apéndice
IV).
DIRECCION Y GESTION DE PROYECTOS TIC 271

H ERRAMIEN TAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
FUNIBER
La in iciación es el proceso de reconocimiento formal de que se va a desarrollar ,

construir de forma material y tangible , la iniciativa e-Business como una solución de
negocio sustentada en una aplicación e-Business compuesta de componentes humanos
y de hardware y software.
El compromiso aborda el desarrollo de un nuevo proyecto o de que un proyecto ya

existente se v a a continuar en su siguiente fase.
Este comienzo formal conecta el proyecto con las operac ion es en curso de la
organización ejecutora. En algunas organizaciones, un proyecto no está formalmente
iniciado hasta tener completo un estudio de viabilidad , un plan pre liminar o alguna forma
equivalente de análisis que , como tal, también ha tenido que ser comenzado
separadamente. Esto involucra trabajar con el cliente para identificar las ent idades clave
en la organización para entrevistarles. <
~
u
"'>:
En particular , algunos tipos de proyectos, especialmente los de servicio interno y los de <
o
desarrollo de nuevos productos (de ingeniería), se inician informa lmente y se reali za una ..::;
pequeña parte del trabajo para asegurar los requisitos necesarios para lograr el
comienzo formal del proyecto.
z
::;)
z
-o
ü
e<
5 . 1. 1 MOTIVACIONES DEL PROYECTO z
...
::i
En la iniciación es importante determinar con claridad el motivo por el cual proyecto se

inicia , la cual puede deberse a alguna o varias de las siguientes causas:
• Una demanda del mercado (po r ejemplo, una compañía petrolífera com ienza un
proyecto para construir una nueva refinería en respuesta a la con tinua escasez de
gasolina).
• Una necesidad de negocio (por ejemplo , una compañía de formación comienza un

proyecto para crear un nuevo curso para aumentar sus ingresos).
• La demanda de un cliente (por ejemplo, un suministrador eléctrico comienza un

proyecto para construir una nueva subestación para abastecer a un nue vo parque
industrial).

FUNIBERÍ~ ...................................... --
H ERRAMIENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
• Un avance tecnológico (por ejemplo, una empresa electrónica comienza un nuevo

proyecto para desarrollar un videojuego, después de la gene r alización del
videocassette).
• Una necesidad legal (por ejemplo, un fabricante de pinturas comienza un proyecto

para fijar las directrices del manejo de materiales tóxicos).
Estas cau sas también pueden llamarse problemas oportunidades , o requerimientos del
negocio. Lo fundamental de todos estos términos es que la d irección suele tener que
tomar una decisión sobre cómo responder a el los. En un proyecto e-Business, esto
significa unir negocio con tecnología.
5.1.2 SELECCIÓN DEL GESTOR DEL PROYECTO
El gestor del proyecto es habitualmente seleccionado al final de la conceptualización del

<
z proyecto, una vez aprobado. El gestor del proyecto es una persona responsable de
<
u
dirigir, gestionar y administrar todo el proyecto.
"'
:!:
<
oa:
.
w
Su responsabilidad centra l es coordina r todas las actividades para satisfacer los
<
...."'<
objetivos del proyecto en tiempo y presupuesto. Su rol es diferente de un líder técnico o
;;;
~ un desarrollador, cuyas responsabilidades se relacionan con la integridad técnica del
>
:3 producto. Entre sus diversas responsabilidades se puede destacar:
~u
<
e
• informar a la dirección;
...5
• comunicación con usuarios;
• planificación y programación;
• coordinación de actividades y tareas;
• control de presupuesto , programa , riesgo y calidad ;
• gestión de personal; y ,
• entregar resultados.
La tarea del gestor es dar visibilidad y gestionar compromisos . Encontrar una persona
para esta tarea no es sencillo , pues pocas personas cumplen con todas las
cualificaciones para proyectos complejos , menos aún que tenga experiencia y esté
disponible. Por este motivo , muchas empresas crean una Oficina de Proyectos para
gestionar mejor los proyectos y crear un pool de futuros gestores.

HERRAMIENTAS Y TÉCNICAS DE GESTI ÓN DE PROYECTOS
FUNIBER
Gestores efectivos deberían tener siguientes habilidades de: comunicación ,

organización, construcción de equipo, liderazgo; negociació n, actu ación por objetivos,
capacidad de trabajo bajo presión y competencia técnica.
Se recalca que la competencia técnica es útil y sirve bastante , pero habilidades de

gestión e interpersonales son más importantes para un gestor de proyectos , de hecho,
tene r ' roce ' en el tra t o de personas, puede ser determinante al momento de escoger el
gestor de un proyecto, más que sus cualificaciones y experiencia técnica . Los gestos
exitosos son generalistas, no especialistas técnicos. Aún más , en muchas ocasiones
provienen de muchas áreas de la organización y no necesariamente del mundo de la
informática.
5.1.3 CAPACITACIÓN
La iniciación no incluye capacitación. La capacitación suele ser un componente clave en

muchos proyectos, pero no es parte de la iniciación, sino que debe planificarse como
una actividad preliminar o inicial, previendo los recursos necesarios y la medición
precisa de haber conseguido conocimiento, competencias y hab il idades requeridas.
<
"'<
Si debe aclararse que quienes part1c1pen en una etapa de in iciación deben ser !::
profesiones experimentados y un buen nivel de capacitación en los temas propias de "'"'

>
z
::i
cualquier iniciación. ._z,
ü
<
o
z
,_"
La planificación requiere un fuerte esfuerzo de estimación para preparar la s acciones

co nducentes a conseguir el producto y cumplir con los objetivos, y de selección de
personal para cumplir con las tareas y actividades definidas. T odo esto da luga r a un
informe de alcance y al plan del proyecto.
Esta es una etapa de comprensión del proyecto e-Business que implica:
• Entrevistar directivos para conseguir comprender el modelo de negocios, la

situación de mercado actual, objetivos y metas de negocio e intenciones iniciales
sobre cómo Internet puede ayudar al logro de los objetivos y las metas.
• Revisar procesos de negocios claves y la infraestructura que les soporta.

FUNIBER f1; HERRAMIENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
miiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;m--
• Revisar y analizar la situación actual frente al potencial uso de entrar en Internet

(presencia de un sitio web con r especto a la visibilidad actual, efectividad como
medio de comunicación , facilidad de uso/ navegación, desempeño completo, solidez
de la arquitectura técnica, etc.).
• Revisar y analizar el actual uso de intranets para promover la comunicación interna

y la compartición de datos.
• Revisar políticas y procedimientos establecidos en los procesos operacionales

asociados o con relación a los potenciales objetivos e-Business.
Además debe hacerse un esfuerzo ma yor en un proyecto e-Business por:
• mitigar los factores de riesgos que plagan los esfuerzos de desarrollo;
• recoger información suficiente para estimar de la maner a más adecuada posible ;
• asegurar que la v isión e-Business sea compartida y esté en concordancia con los
<
z
<
u
objetivos de negocio de la empresa;
"':¡:
< • dar una clara descripción de los requerimientos;
~
"'
:! • asegurar la confianza y escalabilidad del proyecto; y ,
"';':
"'5 • tomar precauciones respecto del coste proyectado .
>
z
::::J
z
·O
ü Todos estos elementos han de aparecer detallados en el Plan del Proyecto y en el
<
o
5 Informe del Alcance.
u.
0
5.2.1 ESTIMACIÓN
a.- Estimación del trabajo
La definición del alcance comprende la subdi v isión de las principales entregas del
proyecto (identificadas en el informe del alcance ) en com ponentes más pequeños y
manejables con el fin de :
• Mejorar la precisión de las estimaciones de costes, programa y recursos.
• Definir las bases para la medida y control de la realizac ión del proyecto.
• Facilitar un a c lara asignación de responsab ilidades.
La adecuada definición del alcance del proyecto es c rítica para el éxito de un proyecto.
Cuando hay una pobre definición del alcance , se puede esperar que se eleven los costes
DI RECCIÓN Y GESTION DE PROYECTOS TIC 275

HERRAM IENTAS Y TÉCN ICAS DE GESTIÓN DE PROYECTOS
FUNIBERff
finales del proyecto deb ido a los inevitab les cambios que interrumpen el ritmo del
proyecto, causan repe t iciones de ta reas, aumentan los plazos de entrega, y disminuyen
la productividad y la moral, de la plantilla.
Una herramienta útil para estimar el trabajo a realizar lo constituye la Estructura de

Descomposición del Proyecto (WorkBreakdown Structure, WBS).
a.1 .- WBS
La base de las actividades de planificación lo constituye el WBS . Un WBS descompone

el proyecto en una estructura jerárquica bien definida de tareas o activ i dades
gestionables, cuya representación puede ser una tabla (ver Apéndice 11) o un árbol.
p El WBS no es una itemización de tareas o recursos, ni tampoco una

especificación de roles o tareas, es la visión de cómo proceder para
llevar adelante el proyecto en sus unidades básicas de trabajo.
<
z
<
~
o:
El número de niveles depende principalmente del tamaño del proyecto y las preferencias "'o<
5
del gestor del proyecto. Es importante que se expliciten todas las actividades necesarias "'<
o:
para completar el proyecto y que sean asignadas a un entidad (pe rso na u organización) <
v;
de manera clara y precisa anulando toda posibilidad de ambigüedad. 5>
z
:::>
z
Un WBS es una agrupación de elementos del proyecto orientada a las entregas del ~
V
<
o
proyecto, que organiza y define el alcance completo del proyecto: trabajos que no estén z
:o
u..
en la EDP quedan fuera del alcance del proyecto. Así, el WBS provee así un marco
fundacional para programar , presupuestar y controlar el proyecto. Una vez definido, el
proceso de estimación comienza. Esto no evita que puedan servir para otros proyectos
o se reutilicen.
La descomposición comprende la subdivisión de las principales entregas del proyecto en

otros componentes más pequeños y manejables de forma que las entregas sean
definidas con suficiente detalle para responder a las futuras actividades de] pro yecto. La
descomposición comprende los siguientes pasos principales:
• Identificar los principales elementos del proyecto . En general, los principales

elementos se rán las entregas del proyecto y la direcc ión del proyecto. Sin
emba rgo , sie mpre se deben definir los principales elementos dependiendo de
como el proyecto sea realmente dirigido. Por ejemplo , las fases del ciclo de v ida
pueden constituir un primer nivel de descomposición , con un segundo niv el
determ inado por las entregas ( ) o por algún otro criterio organizativo
( ).

FUNIBERf~
HE RRAMIENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
. . . . . . .1m:1111E1am. . . . . . . . .111m1. . . . . . . . . . . . . . . . . . . . . . . ._ _
PRODUCTO DE SOFT\VARE
v.5.0
Dirección del Requerimientos Diseño integración

Construcción y prueba
proyecto del producto detallado
Planificación Software Software Software Software
Documentaoón Documentación Documentación Documentación

Reuniones
del usuario del usuario del usuario del usuario
Administración Elementos del Elementos del Elementos del Elementos del

programa de programa de programa de programa de
entrenamiento entrenamiento entrenamiento entrenamiento
<
z Figura 5.1: WBS de una estructura de descomposición por fases 1.
<
!::
::;
>:
...
<
o
w
<
¡;; PLANTA DE TRATAMIENTO DE
<
!:: AGUAS RESIDUALES
::;"'
z>
::i Fases Fases
z
o iniciales posteriores
ü Construcción
<
o
Diseño
z
::>
u.
g Dirección del proyecto Dirección del proyecto
Planos de obra civil

Cimentación
Planos arquitectónicos
Cubeta de aireación
Planos estructurales
Planos mecánicos Est. de bombeo de efluentes
Planos HVAC Zona de tratamiento del aire
Planos de fontenería
Balsa para lodos
Planos de instrumentación
Planos eléctricos
Figura 5.2: WBS de una planta de tratamiento de aguas residuales 2.
l. Esta EDP es únicamente ilustrativa. No trata de representar el alcance completo del proyecto de cualquier proyecto
específico, ni supone que sea este el único modo de organizar la EDP para este tipo de proyecto.

HERRAMIENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
FUNIBER
• Decidir si se pueden realizar las adecuadas est imaciones de duración y costes al

nivel de detalle para cada elemento . El significado de adecuadas puede variar en
el cu rso del proyecto (la descomposición de una entrega que se ha de producir
en un tiempo lejano puede no sea posible). Para cada elemento, hay que pasar
al Punto 4 si se ha logrado el detalle adecuado y al Punto 3 si no es así (esto
quie re decir que los diferentes elementos pueden tener diferentes niveles de
descomposición).
• Identificar los elementos constituyentes de una entrega . Los elementos

constituyentes se deberían describir en términos de resultados verificables y
tangibles, para facilita r la medida de la rea li zación . L os elementos
componentes - del proyecto deben definirse, como se hace con los elementos
principales , en la misma forma como se terminará realmente el trabajo del
proyecto. Resultado s tangibles y verificables pueden i ncluir tanto servicios
como productos (por ejemplo, el informe de situación se puede descr ibir como
informe de situación semanal; para un elemento manufacturado, los elementos
constituyentes podrían inclui r varios componentes individuales más el montaje
final). Repetir el punto 2 para cada elemento constituyente.
<
z
• Verificar si se ha realizado la descomposición correcta : <
u
~
;¡:
¿Son necesarios y suficientes los elementos en el nivel inferior para <
o
comp letar el elemento descompuesto? Si no es así, se deben modificar los "'
w
"'
<
elementos constituyentes (añad ir, eliminar o redefinir).
"':::
~
¿Está cada elemento clara y completamente definido? Si no es así, se deben "'
~
z
revisar o ampliar las descripciones. =o
z
·O
ü
¿Se puede programar correctamente cada elemento? , ¿presupuestar?, <
e
z
¿asignar a una unidad específica de la organización (por ejemplo, un E.
departamento , equipo o persona) que aceptará la responsabilidad de
concluir satisfactoriamente el elemento? Si no es así, se requiere n revis iones
que proporcionen un adecuado control.
a.2 .- Work packages
Cada nivel descendente representa una desc r ipc ión cada vez más deta llada de los
elementos del proyecto. Cada elemento en la EDP es asignado a un único identificado r;
el conjunto de estos identificadores a menudo se denomina código de cuentas. Los
elementos de los niveles más bajos de la EDP se suelen denominar paquetes de trabajo
(work packages). Estos paquetes de trabajo pueden ser descompuestos aún más.
Las descripciones de los elementos de t r abajo se reúnen frecuente men te en un

diccionario de la WBS. Este diccionario incluye generalmente descripciones de paquetes
2. Esta EDP es únicamente ilustrativa. No trata de representar el alcance completo del proyecto de cualquier proyecto
específico, ni supone que sea este el único modo de organizar la EDP para este t ipo de proyecto.

de trabajo así como otra información de planificación como fechas del prog r ama,
presupuestos de costes y asignaciones de personal.
a.3. - Otros tipos de WBS
No se debe confundir una WBS con otros tipos de estructuras de descomposición

utilizadas pa ra presentar información del proyecto. Otras estru ctu r as comúnmente
utilizadas en algunas áreas de aplicación son:
Estructura de descomposición contractual , que se utiliza para defin ir el nivel de

informac ión que el proveedor suministrará al comprado r. La WBS contractual
tiene normalmente menos detalle que una WBS utilizada por el proveedo r para
dirigir su propio trabajo.
Estructura de descomposición organizativa , que muestra qué elementos de

trabajo han sido asignados a qué un idades de la organización . Un organigrama .
Estructura de descomposición de recursos , que es una variación de la

<
z
<
u
estructura de descomposición organ izati va , y se utiliza normalmente cuando se
"':¡:
~ asignan los elementos de trabajo a personas individuales .
<
o
.
~
Lista de materiales, que representa una rel ación jerárquica de los montajes,
<
submontajes y componentes necesarios para fabricar un producto
"'<
....
manufacturado .
E
~
z
=> Estructura de descomposición de tareas , que es prácticamente lo mismo que
z
o una WBS correctamente realizada . La estructu ra de descomposición de tareas
~
o
;;: se utiliza ampliamente en áreas en las que el térm ino WBS es incorrectamente
;r,
utilizado para referirse a una lista de materiales.
b.- Estimación de coste y programación
Los dos enfoques esenciales para estimar el coste y la programación necesaria de un

proyecto son dos.
b.1 . - Enfoque arriba-a-abajo y abajo-a-arriba
Enfoque arriba-a-abajo . Esta es una est imación por analog ías que sign ifica
utilizar el coste real de anteriores proyectos similares como base para la
estimación del coste del proyecto actual. Se usa frecuentemente para estimar
los costes totales del proyecto cuando la información detallada sobre el
proyecto es escasa (por ejemplo , en las fases in iciales de un proyecto ). La
estimación por analogías es una forma de j uicio experto.
La estimación por analogías es generalmente más barata que otras técnicas ,

pero también suel e ser menos precisa. Es más fiable , cuando los proyectos
ante rio r es son realme nte similares y no so lo en apa riencia , y las personas o

H ERRAMIENTAS Y TÉCN ICAS DE GESTIÓ N DE PROYECTOS
grupos de personas que realizan las estimaciones tienen la experiencia

necesaria.
Estimación abajo-a-arrib a. Esta técnica comprende la estimación de costes de

tareas individuales: sumando las estimaciones individuales se consigue el coste
total del proyecto. El coste y la precisión de la estimación de abajo-a-arriba
depende del tamaño de las tareas individuales: cuanto más pequeñas son las
tareas tanto más se incrementa el coste como la precisión. El equipo de
dirección del proyecto debe sopesar si la precisión adicional justifica el mayor
coste.
Ambos métodos o enfoques se usan en conjunto y se requieren varias

iteraciones hasta alcanzar resultados que puedan considerarse satisfactorios .
b.2 .- GANTT, PERT y CPM
b. 2 . 1.- Características
Conseguir una buena programación es un reto, no obstante es razonable y alcanzable. <

z
<
Ella debe tener el compromiso del equipo al completo, para lo cual se recomienda que "'
~
cada miembro o grupo del equipo determine las tareas a realizar y el tiempo para "
<
o
cumplirlas. ~
<
"'<
t:
La programac1on para grandes proyectos usualmente comprende un programa máster, "'~
>
mostrando principales actividades e hitos y dej ando el detalle en sub-programas. z
::>
z
e
u
<
La forma más común de presentar un programa es una carta GANTT que muestra las e
;:
.::
actividades contra una escala de tiempo horizontal ( ) . Las cartas GANTT son
herramientas populares para comprender y facilitar la creación y revisión del prog rama .
Esto da lugar a una red de programa que muestra las ínter-relaciones.
280 DIRECCIÓN Y GESTION OE PROYECTOS TIC

FUNIBERf~ .........................................
HERRAMI ENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
Nombre de tarea Duraoón Comienzo Flll Predeces '99 23 ago '99 13 sep '99 4 oct '99 25 oct '99 15 nov '99 6 die '99
ln1c10 Os 06/09199 06/09.'99 14 22 30 7 15 23 1 9 17 25 2 10 18 26 4 12 20
Establecer tos requern1entos 3s 06/09,'99 24/09/99 1 6C>'i
Seleccionar los dnvers 06/09/99 17/09/99 1 T
2s
T
Hacer el diseño 45 27/09/99 22/10/99 2
Recoger datos 2s 01/11/99 12/11/99 2;3;6
~.
,.
Probar los drivers
Codificar
6s
4S
20/09/99 29/ 10/99 3
25/10/99 19/ 11/ 99 4
T
T
..
Hacer la dOOJrnentaoón 15/11/99 26/11/99 4,5 T
2s
T
Probar el producto 4s 22 111/ 99 17/12/99 5;6;7
10 Fina Os 17/ 12/99 17/12/99 9,8 " 17 ·12
Nombre de tarea Duraoón Predecesoras Nombres de los recursos

l ln!CIO Od
2 E~tablecer los requenm1entos 3d A
3 Seleccionar los drivers 2d 1 B
4 Hacer el diseño 4d 2 A
5 Recoger datos 2d 2;3;6 B
6 Probar los drivers 6d 3 B
7 Codificar 4d 4 A
<
z 8 Hacer la documentac1on 2d 4;5 B

z
::>
z
o
Estas ínter-relaciones se muestran habitualmente como redes PERT (Program Evaluation
ü
o< Review Technique , ) y CPM (critica/ path meth od ) . Ambos métodos so n
z
:>
u. bastante similares en el uso de flujogramas , grafos o redes de dependenc ia para mostrar
las ínter-relaciones.
3. BARCELÓ, M. (1999). Lagestiód'unprojecteinformatic. Edit. UOC. Pp. 15-16.
DIRECCI ÓN Y GESTIO N DE PROYECTOS TIC 28 1

H ERRA MIENTAS Y TÉCNICAS DE GESTIÓ N DE PROYECTOS
(O, 3) (3, 7) (7, 9)
2 4 8
Establecer los Hacer el Hacer la
requerimientos • diseño • documentación
(3) (4) (2)
(O, O) "' (3, 5) "' (7, 11} "' (15, 15)
5
7 10
Recoger
Jmao Codificar Rnal
datos
(O) (4) (O)
(2)
" •
(2, 8)
(0,2) (11, 15}
3 6 9
Seleccionar Probar los Probar el
los drivers drivers producto
(2) (6) (4) <
:¡
u
"'
:r
<
• Camino critico o
~
"'<
"'<
....
Actividades, duración y precedencias de un proyecto ficticio "'~
>
Identificación numérica Nombre de tarea Duración Predecesoras z
=>
1 I nicio o z
o
2 Establecer los requerimientos 3 1 ü
<
o
3 Seleccionar los dnvers 2 1 z
4 Hacer el diseño 4 2 "'

LL
5 Recoger datos 2 2;3;6

6 Probar los drivers 6 3
7 Codificar 4 4
8 Hacer la documentación 2 4;5
9 Probar el producto 4 5;6;7
10 Final o ~
Figura 5 .4: PERT4.
Otra ventaja de las redes de prog ramació n (sched ule networks ) es que pueden usarse
p ara ide ntifi car y seguir el cam in o crít ico de l proyect o .
Todos estas técnicas de r epresentació n , so n ins t anc i as de un diagrama de

precedencias.
4. BARCELÓ, M. (1999). Lagestiód'unpro;ecteinformatic. Edit. UOC. Pp. 9- 10.
282 DIRECCIÓN Y GES- ION DE PROYECTOS TIC

FUNIBER f~ ........................................................ --
HE RRAMIENTAS Y TÉCNI C AS DE GESTIÓN DE PROYECTOS
b .2.2.- Ventaja s y desventajas de los gráficos Gantt
" La ventaja principal del gráfico de Gantt r adica en que su trazado requiere un nivel
mínimo de planificación, es deci r , es necesario que haya un plan que ha de
representarse en forma de gráfico. La técnica descrita de este capítu lo representa y al
mismo tiempo ayuda a la elaboración del plan de trabajo. Los gráficos de Gantt se
revelan muy eficaces en las etapas iniciales de la pla nif icación. Sin embargo , después
de iniciada la ejecución de la actividad y cuando comienza a efectuarse modificaciones,
el gráfico tiende a volverse confuso. Por eso se utiliza mucho la representación gráfica
del plan, en tanto que los ajustes (replanificación) requ ieren por lo gene ral de la
formulación de un nuevo gráfico. Para superar esa deficiencia se crearon dispositivos
mecánicos , tales como cuad r os magnéticos , fichas , cuerdas, etc ., que permite una
mayor flexibilidad en las actualizaciones. Aún en términos de planificación, existe
todavía una limitación bastante grande en lo que se refiere a la representació n de planes
de cie rta comp lejidad. El Gráf ico de Gantt no ofrece condiciones para el análisis de
opciones , ni toma en cuenta factores como el costo. Es fundamentalmente una técnica
de pruebas y errores. No permite, tampoco, la visualización de la relación entre las
activi dades cuando el número de éstas es grande 5 ".
b .2.3.- Diferencia entre PERT y CPM
"La diferencia entre PERT y CPM es la manera en que se realizan los estimados de
::
::> tiempo. El PERT supone que el tiempo pa ra realizar cada una de las act ivi dades es una
"
·O
':::. variabl e aleato r ia descrita por una distribución de probabi lidad. El CPM por otra parte ,
o
"
::>
"-
infie re que los tiempos de las actividades se conocen en forma determinísticas y se
puede va riar cambiando el nivel de recursos utilizados 6 " .
b.2.4 .- Comparación de los Gráficos Pert y Gantt
" Estos gráficos se presentan fre cuentemente como herram ientas de gest ión de
proyectos mutuamente excluyentes. Normalmente, se recomienda PERT para grandes
proyectos con alta dependencia entre las tareas: Gantt, por su parte, se recomienda
para proyectos más sencillos. T odos los proyectos de desarrollo de sistemas tienen
algunas dependencias entre tareas y ofrecen la ocasión de solapar tareas. Por
consiguiente, los gráficos PERT y Gantt deberían utilizarse como herramientas
complementa rias para planear, programar, evalua r y controlar los proyectos de
desarrollo de sistemas. Por lo general los directores de proyectos de sistemas de
información prefieren los gráficos Gantt por su sencillez y su capacidad para mostrar el
calendario de un proyecto. En los paquetes de software de gestión de proyectos reúnen
S. HINOJOSA, MARÍA. (2003). Diagram de Gantt

Enlace web: 1tto. Nv1'. .gest OROI c;_com1 recu-scsidocurnen:oc/fu ldocc/cerid agrc::· ta:eia.htm
6. ROJAS, JOSÉ. (2003). Técnicas de planeación.
En lace web: "tto ...... gesc.opc s cor rec ·s,.s docume~'º' fullco:s cer'teco" frz, "t01

H ERRAMIENTAS Y TÉCNICAS DE GE STIÓN DE PROYECTO S
FUNIBER
las mejores ca r acterísticas de PERT (sob re todo, el análisis del camino c riti co)
inco rporadas en gráf icos de Gantt. Cuando se introducen las t areas , se i ncluyen
también su duración y sus dependencias. Las barras de Gantt se planifican en el tiempo
de manera que tengan en cuent a sus dependencias. Por lo general el camino critico se
resalta con mayor intensidad. Además , también se destaca la cantidad de t i empo
muerto apreciada en las tareas de caminos no críticos. Est a presentación puede probar
su uti lidad cuando se decida que tareas se retrasarán con obj eto de consegui r recuperar
el tiempo en las tareas que supe ran los plazos previstos 7 ".
b.3.- Diagrama de precedencias
Este es un método de elaborar un diagrama en red del proyecto usando nodos , que
re pr ese nt an l as ac t iv id ades, co nectad o s m edi a nte fl echas , que mu est ran las
dependencias ( ) : el método del diagrama de precedencias. Esta técnica se
denomina también actividades en los nodos y es el método utilizado en la may oría de los
programas de software para la gestión de p r oyectos. El método del d iagrama de
precedencias se puede realizar manualmente o med iante ordenador . <
z
<
~
"'>:
<
o
.,"'w
"" A "" B
"'
"'
Comienzo Fin w
~
z
::>
z
o
_ _ _ ... E ;:;
"" D F <
e
z
"'
u..
Figura 5.5: Diagrama de precedencias.
El método incluy e cuatro tipos de dependencias o relaciones de precedencia:
• Terminación-a-comienzo: la act ividad inicia l debe terminar antes de que la activ idad
final pueda comenzar;
• Terminación-a-terminación: la actividad inicial debe term inar antes de que la

actividad final pueda terminar ;
• Comienzo-a-comienzo : la activ idad inicial debe comenzar antes de que la act ividad
final pueda comenzar ; y ,
• Comienzo-a-terminación : la act ividad inicial debe comenzar antes de que la

actividad f inal pueda t erminar.
7. PEÑA, RODRIGO. (2001). Gestión de Proyedo.

En lace web: ip .. , . ., r.q:or>0 < rom • r ~·<o<ldoCL;rnenro< 'u ldoc<{C'e" oe<:•oproyecto.bt:n

HE RRAMIENTAS Y T ÉCNICAS DE GESTIÓN DE PROY ECTOS
En el método del diagrama de precedencias, el tipo más habitual de relación lógica es el

terminación-a-comienzo. La s relaciones comie n zo-a-terminación se utilizan rara vez y
cuando se utilizan, es únicamente por ingenieros de programación profesionales. Usar
1as r e 1a c iones comienzo-a -comienzo , t e r minación-a-terminación o
comienzo-a -terminación con el software para gestión de proyectos puede producir
resultados no esperados, ya que estos tipos de relaciones no han sido suficientemente
probados.
Otros métodos similares son :
• Método del diagrama de flechas . Este es un método de elaboración de un diagrama

en red del pr oyecto que utiliza flechas para representa r las actividades y las
conecta a nodos que muestran las dependencias ( ). Esta técnica también
se denomina actividades en las flechas y, aunque menos corriente que el método
del diag r ama de precedencias , es la técnica que se elige en algunas áreas de
aplicación. El método del diagrama de flechas utiliza solamente dependenc ias
~ terminación-a-comienzo y puede necesitar el uso de actividades fictici as para
~
~ definir cor rectamente todas las relaciones lógicas. El método del diagrama de
:¡:
<
~ flechas se puede realizar manualmente o mediante ordenado r.
"'
<
"'<
Comienzo A
. B
~
e
... .
.. ...
D 4 F Fin
E
Figura 5.6: Diagrama de flechas.
Reglas para construir el diagrama de flechas :
1. Cada actividad está representada po r una y un solo una flecha en la red.

Ninguna actividad puede representar se dos v eces en la red .
2. Dos actividades diferentes no pueden identificarse por los mismos eventos

terminal y de inicio.
D IRECCION Y GESTIÓ N DE PROYECTOS TI C 285

FUNIBER~
H ERRAMI ENTAS Y TÉCNICAS DE GESTIÓ N DE PROY ECTOS
3. Al fin de asegurar la relación de precedencia correcta el diagrama de flechas ,

las siguientes preguntas deben resp onderse cuando se agrega cada actividad a
la red:
¿Qué actividad debe terminarse inmediatamente antes de que esta actividad

pueda comenzar?
¿Qué actividades deben seguir a esta actividad?
¿Qué actividades deben efectuarse simultáneamente?
• Métodos de diagramas condicionales. Las técnicas de diagramas tales como los

modelos GERT (Técnica de Revisión y Evaluación Gráfica) y sistemas
dinámicos , permiten tratar actividades no secuenciales tales como lazos (por
ejemplo una prueba que se debe repetir más de una vez) o condicionadas (por
ejemplo , una actualización del diseño que sea solamente necesaria si la
inspección detecta errores). Ni el método del diagrama de precedencias ni el
método del diagrama de flechas permiten tratar lazos o actividades
condicionadas.
<
• Redes patrón . Se pueden utilizar redes normalizadas para facilitar la preparación z
<
u
de los diagramas en red del proyecto. Pueden incluir un proyecto completo o §
solamente una parte de él. A las partes de una red se las suele denominar "o<
subredes o fragmentos de redes. Las subredes son especialmente útiles cuando ~
<
un proyecto incluye varias partes idénticas o casi idénticas, como las plantas de "'1-<
un edificio alto de oficinas, los ensayos clínicos en un proyecto de investigación v;
:::>
farmacéutica , o los módulos del programa en un proyecto de software. z
:::>
z
~
b.4. - Camino crítico u
<
e
z
;f.
El camino crítico del proyecto es el conjunto de actividades que toma mayor tiempo
completarlo. En esencia , el camino crítico determina cuando el proyecto terminará. Las
tareas en el camino crítico requieren atención especial de la gestión debido a que no
dejan espacios libres u holguras en la programación, de hecho no puede atrasarse bajo
ningún concepto.
Debe hacerse notar que un proyecto puede tener muchos caminos críticos y que las
v ariaciones en la duración de las tareas puede ir de un camino a otro. El camino critico
resulta también de utilidad para identificar programaciones de riesgo.
El camino crítico es una técnica análisis matemático que comprende el cálculo teórico
para el comienzo y terminación , con mayor antelación y mayor r etraso , de todas las
actividades del proyecto sin tener en cuenta las limitaciones del conjunto de recursos.
Las fechas resultantes no son el programa , sino que indican los periodos de tiempo
dentro de los que la acti vi dad debe ser programada , dadas las limitaciones de los
recursos y otras restricciones conocidas .

FUNIBER f~ ............................................
H ERRAMI ENTAS Y T ÉCN I CAS DE GEST IÓN DE PROY ECTOS
En esencia, el Método del Camino Crítico es un método de optimización que calcula una
fecha de comienzo y terminación, la de mayor adelanto y la de mayor retraso , para cada
actividad , basándose en la secuencia de relaciones lógicas ya especificada y en la
simple estimación de duraciones . El objetivo del mét odo del camino crítico es ca lcular el
ma r gen con el fin de dete r mina r qué actividades tienen la menor flexibilidad de
prog ramación . Los algoritmos del método del camino c rítico se utilizan a menudo en
otros tipos de an álisis matemático.
Algunas va riaciones ocu rren respecto de un GERT y un PERT.
• GERT. Permite el tratamiento probabilístico tanto de las relaciones lógicas como de

las estimaciones de la duración de las actividades (por ejemplo , algunas actividades
pueden no desarrolla r se , otras se pueden desarrollar solamente en parte, y otras
pueden desarrollarse más de una vez).
• PERT. Utiliza las relaciones lógicas secu enciales y una media ponderada de la
estimación de duraciones pa r a calcu l ar la duración de l p royecto. Aunque hay
diferencias superficiales, el PERT difiere del GERT principalmente en que utiliza el
concepto de distribución (valor esperado) en luga r de la estimación más probable
origina lmente utilizada en este último ( ) . El PERT en sí mismo apenas se
.
:!:
<
::::
usa hoy en día , aunque las estimaciones realizadas para el PERT se usan
"'~ frecuentemente en los cálculos del CPM.
>
"
::>
z
~
V
<
o Mayor Valor más probable
5
u.. (utilizado en los cálculos iniciales(
del Método del Camino Crítico) Medida ponderada del PERT= )
Opt1m1sta + 4"' Más ¿robable + Pes1m1sta
Probabilidad
relativa de
ocurrencia
D1stnbuc1on Beta
Valor Valor
Menor optimista pesimista
Menor Mayor
Duración posible del proyecto
Figura 5.7: Cálculo de la duración de un proyecto mediante PERT.
Un caso especial de análisis matemático es la reducción de plazos , que busca la manera

de reducir el programa del proyecto sin alterar su alcance (por ejemplo , lograr las fechas

FUNIBER
impuestas u otros objet ivos del programa) . La reducción de plazos inc luye t écnicas tales
como:
Crashíng . Es una técnica en la que se analizan el cost e y los cambios del

programa pa ra dete r minar cómo obtene r la mayor reducción posible con el
meno r incremento de costes. El crashing no siempre produce una alternativa
viable y da lugar, frecuent emente , a un incremento de los costes .
- Cam ino acelerado . Consiste en real izar actividades en paralelo que normalmente
se realizarían en se rie (por ejemplo, empezar a codificar en un programa de
software antes de completar su d iseño, comenzar a constru ir las c imentaciones
para una refinería de petróleo antes dé realizar el 25 por ciento de la labor de
ingeniería, o empezar a comprar hardware sin tener definida la infraestructu ra e-
Business ). No rmalmente esta técnica conduce a repetir tareas y frecuentemente
incrementa el riesgo.
b .5 .- Programa del proyecto <

z
<
~
~
El programa del proyecto 8 incluye al menos las fechas planeadas de comienzo y las >:
<
o
previstas de te rminación pa ra cada actividad. "'w
"'
El programa del proyecto se puede presenta r en forma de resumen (el " programa
básico") o en detalle. Aunq u e puede presenta rs e en forma de tabla , es más frecuen t e
presentarlo gráficamente, utilizando uno o más de los siguientes formatos : 5
;,;
<
e
z
::>
Diagramas en red del proyecto con información añ adida sobre fechas . Estos u..
diagramas normalmente muestran la lógica del proyecto y las actividades del

camino crítico del proyecto .
Diagramas de barras , también llamados diag ramas de GANTT. Muestran las

fechas -de com ienzo y terminación de las acti vidades así como las durac io nes
esperadas, pero normalmente no muestran las dependencias . Son relati vamente
fáciles de interp retar y se usan frecuentemente en los informes de dirección .
Diagramas de hitos. Son similares a los diagramas de barras ( ), pero

identifican el comienzo o la term inación programados de las principales entregas
y las conexiones externas clave.
8. El programa del proyecto se considera preliminar hasta que la asignación de recursos ha sido confirmada. Esto
normalmente ocurre antes de la terminación del desarrollo del plan del proyecto.

HERRAMIEN TAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
" .
Suceso Ene Feb Mar Abr May Jun Jul Ago
Firma de subcontratos
Term1nac1ón de especificaciones
Revisión del diseño
Prueba del subsistema
Entrega de la pnmera unidad
Terminación del plam de producaón
Figura 5.8: Diagrama de hitos9 .
Red dimensionada . Es una mezcla de diagramas en red del proyecto y de

diagramas de GAN TT en la que se muestra la lógica del proyecto, la duración de
las actividades y la información del prog rama ( ).
<
:;"
;:"' A e E G
<
;¡ 1 • 3 • 7 • 11 • 12 • 14
.....
::o.
<
¡; ...
~
... ...
~ B D F H
z
;;)
:::
• 5 • 6 • 9 • 13 • 15
·O
u
o<
:::
...
::>
o 2 3 4 5 6 7 8 9 10 11 12 13 14
"'
Tiempo
Figura 5.9: Red dimensionada 10 .
9. Hay otras muchas maneras válidas para mostrar la información sobre un proyecto en un diagrama de hitos.
10. Hay otras muchas maneras válidas para mostrar la información sobre un proyecto en una Red dimensionada.
DIRECCIÓ N Y GEST!ON DE PROYECTOS TIC 289

HERRAMIENTAS Y TÉCNICAS DE GESTIÓN DE PRO YECTOS
FUNIBER
Ejemplo :
HACER SOFnVAAE
Programadores
Equipo de
Hablhdades
traba¡o
Leer Tool
Don de gente
Formaoón
Nivelar
Mane¡o <le Aphcaoon de

PubllCldad Oas1ficados STDR
oomple¡1di'd conceptos
Sel. MedtOS
TEST
Pl'gar
Hace• Ahále
Figura 5.10: Actividades para el desarrollo de Software.
Para este ejemplo tenemos algunas acti vi dades realizadas p or el ultimo nivel, entre est as
<
están: a:
~
¡¡;
"'
~
• Test . z
:::>
5
• Aplicación de Conceptos. ..
u
o
z
::>
• ST DR . u..
• Prueba de Nivelación.
• Leer Tool.
• Don de Gente .
• Manejo de Stress y Complejidad .
• Pre-Contrato.
• Conv encerlos .
• Plantilla.
• Selec. Clasif .
• cv.
• Hacer Afich.
• Pegar .
• Sel. Medios.
• Claridad .

FUNIBER f~
. . . . . . . .: . -. . . . . . .aZl. . . . . . . . . . . . . . . . . . . . . .. .
Por ejemplo si quisiéramos analizar la prueba de niv e lación, tendr íamo s que ha cer lo
siguiente :
Para cada proceso de tercer ni v el como los que hemos descr ito ant er iormente ,
definiremos , que tareas se realizaran primero , y c ual despu és , y ad emá s, cada tarea
deberá tener asignado alg ú n costo y tiempo que se tomara en rea lizar lo .
2-SlO 4-$80 5-$30

. B .o . G
1-513 4-528 3-512
e . E H
3-518
• A 5·$5
. F
<
z
:
~
Figura 5.11: Grafo de Procesos.
<
o
.
"'
~
Una v ez que y a hemos realizado este paso , pro cedemos a re alizar la c arta Gantt .
El gráf ic o Ga n tt muestra un formato de un gráf ic o de t iempo; la co lum na de l lad o

izquierdo enfatiza las tareas a realizar, la fil a superior indi c a el t iem po en que se da rá
esa tarea . Para tener prev isto las semanas en que se tendrá m as activi dad es y como se
las gestionará .
.-
.---:
-··y ;•:- '.. ,;-- ..-,.._.~~-- ' -...., .. , i-J: ~ or, ,r.1r1.
~-~
e~"'· ,r.I~ - ~· ·""'·I~ L· r.11r...:!i ~.
. 1r.ib1
1, 1,1 Identificar necesidades y beneficios
Reunirse con los clientes
Identificar las necesidades y las
limitaciones
del proyecto
Establecer la declaración del producto
Hito: declaración de producto definido
Definir las salidas/ controles/ entradas

1,1,2
deseadas (SCE) 1
Alcance de las funciones del teclado
1 Alcance de las funciones de la entrada de
voz 1
Alcance de los modos de interacción
1 1
Alcance de documento de diagnostico
Alcance otras funciones WP
Documento SCE
D IRECCIÓN Y GESTION DE PROYECTOS TIC 291

FUNIBER
1
~ J.."!"'-l ,,., .,., lfl
"
. . ..:u~~
.... ::..i r: 11 • ·- ¡::;:,"'' "" •r. LQ i:: "'""' ,, .r::1
RTF: revisar el SCE con el cliente
!
Revisar el SCE segun se requiera
Hito: SCE definido
1,1,3 Definir la funcionalidad/ comportamiento
Definir las funciones del teclado
Definir las funciones de entrada de voz
Describir los modos de interacción

Describir las comprobaciones de
ortografía/ gramática
Describir otras funciones WP
RTF: Revisar la definición SCE con el
cliente
Revisar segun sea necesario
Hito: Definición de SCE completa
1,1,4 Aislar los elementos software
Hito: Elementos software definidos <
z
:
existente <
o
Investigar los componentes de edición de ~
texto "'<
"';::
I nvestigar los componentes de la entrada
de VOZ
¡:¡
u
1 >
Investigar los componentes de la
z
::::>
z
administración ·O
ü
<
de archivos o
z
::>
u.
Investigar los componentes de la 1
comprobación
de ortografía y gramática
Hito: Componentes reutilizables
identificados
1,1,6 Definir la viabilidad técnica
Evaluar la entrada de voz
Evaluar la comprobación de gramática
Hito: Viabilidad técnica valorada
1
1,1 ,7 Hacer una estimación rápida del tamaño
1,1,8 crear una definición de ámbito
Revisar el documento de ámbito con el
cliente
Revisar el documento segun se requiera
Hito: Documento de ámbito completo 1
Tabla 5 .1. Carta Gantt.

FUNIBER f~ r::ilillimma:=-mzm::c::::=:!::::::===================:=::::i
A partir de esta gráfico del tiempo , se producen las tablas de proyecto ( ), que
son un listado de todas las tareas del pro yecto, sus fechas previstas y reales de inicio y
final izació n , e información varia sobre el t ema. Con esto el gestor puede ver cuando se
realizan las tareas como han progresado y cuand o conc luyen.
., - . w. ..
11
. ,
'e> r
·' ' .
identificar
..
\l:::., 1- ·~
::-..• .... :..a.•..t1L....¡i1"1
~~ ' :•:.· 1 ..:·.~
..
,
... . ..1.· • 11' ~ ..1 r.
1, .
:...~.,;._"'ltllP:L. .
F!\.'11• • 1 ... • ~ot 1 11 ,.. ' •
1,1,1 necesidades y
beneficios
Reunirse con los Sem 1,d2 BLS 2pd Es previsible
Sem 1,dl Sem 1,dl Sem 1,d2
clientes
Identificar las
necesidades y las Sem 1,d2 Sem 1,d2 Sem l,d2 Sem l,d2 JPP 1pd que requle•a
limitaciones
del proyecto mas esfuerzo/
Establecer la
declaración del Sem 1,d3 Sem 1,d3 Sem 1,d3 Sem 1,d3 BLS/JPP l pd tiempo
producto
< Hito: declaración de
z Sem 1,d3 Sem 1,d3 Sem 1,d3 Sem 1,d3

z Ambito de las
:::> funciones de la Sem l,d3 Sem 1,d3 Sem 2,d2 JPP 2pd
z entrada de voz
•!:!
u
<
o Amb1to de los modos
Sem 2,dl Sem 2,dl Sem 2,d3 MLL 1pd
5
u.
de interacción
Ambito de
documento de Sem 2,dl Sem 2,dl Sem 2,d2 BLS 1,5 p d
diagnostJco
Amb1to otras
Sem l,d4 Sem 1,d4 Sem 2,d3 JPP 2pd
funciones WP
Documento SCE Sem 2,dl Sem 2,dl Sem 2,d3 MLL 3pd
RTF: revisar el SCE
Sem 2,d3 Sem 2,d3 Sem 2,d3 Todos 3pd
con el cliente
Revisar el SCE segun
Sem 2,d4 Sem 2,d4 Sem 2,d4 Todos 3pd
se requiera
Hito: SCE definido Sem 2,d5 Sem 2,d5 Sem 2,d5
1
Definir la
1,1,3 funcionalidad/
comportamiento
Tabla 5.2. Tabla de Proyectos.
c.- Estimación de coste y presupuesto
Otra s tareas de estimación son de coste y presupuesto. En un proyecto informático, el

coste del presupuesto se mide en fun ción de las horas de esfuerzo dedicadas a las

HERRAMIENTAS Y TÉCNICAS DE GEST IÓN DE PROYECTOS
tareas. La estimación es un análisis histórico ajustado a las capacidades y habilidades

de cada miembro.
La estimación cubre todas las actividades del WBS, incluyendo la propia gestión del
proyecto y sus funciones de apoyo , como el aseguramiento de la calidad y el
seguimiento de los planes de riesgo, por ejemplo. La estimación debe incluir costes
directos no laborables, y los costes indirectos o de overhead. Los costes directos se
calculan de las horas-hombre multip licadas por su valor de mercado o acordado. Los
costes directos no laborables incluyen outsourcing, consultores , viajes, cenas , etc.
El presupuesto total del proyecto es determinado agregando todos los costes directos e
indirectos. Es buena práctica incluir salvaguardas de gestión para contingencias y
problemas no anticipados. Una reserva del 5 al 10% no es extraña usual y puede ser
mayor en proyectos mayores o de alto riesgo.
El presupuesto debe asignarse a individuos u organizac iones siguiendo el WBS. El

presupuesto marca la línea base (baseline ) sobre la cual medir el desempeño del
proyecto. Una herramienta adecuada es la curva-s que muestra los costes acumulados ,
la cual provee la representación gráfica del presupuesto en función del tiempo según la
programación del proyecto. <
;;:
<
....
¡¡;
"'~
z
=>
Coste acumulativo z
~
s u
<
e
z
:l
u.
Ene Feb Mar Abr May Jun Jul
Figura 5.12: Curva de coste acumulado.

HERRAMI ENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
5.2.2 CONFORMACIÓN DEL EQUIPO
5.2.2.1 Selección de los miembros del equ ipo
La ejecución de un proyecto es como los deportes, la diferencia entre el miembro más

p r oduct i vo y e l menos produc ti vo puede ser amp l ia. No obstante se deberían
seleccionar los mejores.
Po r este motivo es impo rtante ten er en consideración que las habilidades a buscar no
son solamente técnicas, sino habi li dades para solucionar problemas e interpersonales.
Aún más, debe recordarse siempre que un buen m iembro tiene una alta auto -estima y
un fuerte compromiso hacia el éxito de un proyecto .
Cualquier Test a realizar debe crea r equipos con una mezcla equilibrada de habilidades y
personalidades. Muchos prog ramadores o pe rsonas del ámbito técnico son personas
z<
introvertidas y pensativas que basan sus decisiones en hechos en luga r de sentimientos
<
!::! y valo res personales. Ellos tienen a encontrar dificultades en constru ir relaciones y ver
"':¿
~
<
o el proyecto desde el punto de vista del usuario. Por ello , formar un equipo equilibrado no
.."'
w
es una labo r sencilla .
..
::!
<
~
~ 5.2.2.2 Estructu ra organ izacional
::;¡
z
~
V
<
o
z
La estructura organizacional frecuentemente condiciona la disponibilidad o los términos
:::>
u..
e· en los que se puede disponer de los recu r sos para el proyecto. Las estructuras
organizacionales de un proyecto cu bren un amplio espectro que va desde la estructura
funcional a la organización por proyectos , con distintos tipos de estructu ras matriciales
entre ambas. La detalla las características c lave de los principales tipos de
estructuras de organización reseñadas.
DIRECCIÓN Y GESTJON DE PROYECTOS TIC 29 5

Matricial
Débil Equilibrada Fuerte
Autoridad del director del Poca o Baja a
Limitada Moderada a alta Al ta a casi total
proyecto ninguna moderada
Poca o Baja a
Disponibilidad de recursos Limitada Moderada a alta Alta a casi total
ninguna moderada
Quien controla el presupuesto Gerente Gerente Director del Director del
Combinación
del proyecto funcional funcional proyecto proyecto
Dedicación Dedicación Dedicación Dedicación Dedicación
Rol del director del proyecto
parcial parcial completa completa completa
Personal administrativo de la Dedicación Dedicación Dedicación Dedicación Dedicación
dirección de proyectos parcial parcial parcial completa completa
Tabla 5.3. Características de estructuras organizacionales 11 .
a.1.- Estructura organizacional funcional z<

<
u
"'~
<
La o rganización funcional c lásica mostrada en la es jerárquica, en la que o
~
cada empleado tiene un superior definido . El personal está agrupado po r especialidades , ::
como producción , marketing, ingeniería y finanzas en el nivel más alto; con la ingeniería "'::.
"'"'
div id ida además en mecánica y eléctrica . >
z
:::>
z
·O
Las organizaciones funcionales todavía tienen proyectos, pero lo que perciben de dichos ü
<
e
proyectos se restringe a lo que son sus funciones: el departamento de ingeniería de una 5
U-
organización funcional hará su trabajo independientemente de los departamentos de

fabricación o marketing.
Por ejemplo , cuando se lle va a cabo el desarrollo de un nue vo producto en una

organización puramente funcional , la fase de diseño se denom in a frecuentemente
proyecto de diseño e incluye únicamente personal del departamento de ingeniería. Si
aparecen dudas o p r eguntas sobre la fabricación , éstas se trasladan al jefe del
departamento, quien las consu lta con el jefe del departamento de fabricació n. El jefe del
departamento transmite después la respuesta al director del proyecto de ingeniería.
11. PMBOK. ( 2004). Guía de los Fundamentos de la Dirección de Proyedos. De PMI-Project Management Institute.
Standards Comm itte. Asociación Española de Ingeniería de Proyectos.

FUNIBER ff ..................................................__
HERRA MI ENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
Coordinación
Director
del proyecto ejecutivo
/
-----------~--------------------- ---------------------------------- ' ~ 1
{
/
Gerente Gerente Gerente
')
\ funcional funcional funcional /
'' /
,___ ------------------------- ------------------------ -------------~

/
Personal Personal Personal
<
(las casillas azules representan al personal que participa en las actividades del proyecto)
z
:
<
o Figura 5. 13: Estructura organizacional funcional.
"'w
"'
a.2. - Estructura organizacional por proyectos
En el lado contra r io del espectr o está la o rganización por proyectos most r ada en la
. En u na o rganización po r p royec t os , los m iemb r os del equipo están a
menu do asignados permanentemente . La mayoría de los recursos de la organización
intervienen en las labores del proyecto y los d irectores de proyecto tienen una gran
independencia y autoridad. Las o rganizaciones po r proyectos tienen frecuentemente
unidades de organización denominadas depart amentos, pero estos grupos, o informan
directamente al director del proyecto o propo rcionan serv ic io s de apoyo a los distintos
proyectos.

HERRAMIENTAS Y TÉCNI CAS DE GESTI ÓN D E PRO YECTO S
FUNIBER f-;
Coordinación Director
del proyecto ejecutivo
!
,----------~---- '
1 l
Director Director Director
del proyecto del proyecto del proyecto
1
1 Personal Personal Personal
1
'- --------------- ~ <
z
(las casillas azules representan al personal que participa en las actividades del proyecto) 
z
=>
z
~
Las organizaciones matriciales, como las mostradas en la y la u
<
o
z
son una mezcla de las organizaciones funcionales y por proyectos. Las matrices débiles c.
mantienen muchas de las características de una organización funcional y el papel del
director del proyecto es más el de un coordinador o activador, que el de director. Del
mismo modo, l as matrices fuertes tienen muchas de las características de las
organizaciones por proyectos directores trabajando totalmente para el proyecto con
considerable autoridad y un equipo administrativo dedicado totalmente al proyecto.
298 D IRECCIÓN Y GESTION DE PROY ECTO S TI C

HERRAM IENTAS Y TÉ CNICAS DE GESTI Ó N DE PROYECTOS
FUNIBERiJ i;;;;;;;;;:;;;;;¡;;;;;;;;;;;;;;;;¡¡¡¡;¡¡;¡;z:¡CIC:::msc:m. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .
Director
ejecutivo

funcional funcional funcional

---------------------- ------------------------- --------------,
( Personal Personal Personal )
'------------------------------------------------------------------""\.
(las casillas azules representan al personal que participa en las actividades del proyecto) Coordinación
del proyecto
<
z
<
Figura 5.15: Estructura organizacional matricial débil.
.,,
::"'
z
Director
:::;¡ ejecutivo
z
-O
ü
<
o
z
::>
'--

funcional funcional funcional
------------------------ ------------------------ -------------, '\

/ Director Personal Personal
( del proyecto )
',, /
---- --------------------------------------------------------- - --<""

~
eoord.1naaon
·
(las casillas azules representan al personal que participa en las actividades del proyecto) del proyecto
Figura 5.16: Estructura organizacional matricial equilibrada.

HERRAM IENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
FUNIBER
loir~
~u~~ 1
Gerente Gerente Gerente Director de

funcional funcional funcional directores del proyecto
Personal Personal Personal Director del proyecto
~
-------------------, ·...
____ _Personal
(.... Personal Personal Director del proyecto
___ ,,,,,,. }
------------------------------------------------------------- --------,----------
(las casillas azules representan al personal que part1c1pa en las act1111dades del proyecto) Coord1nac1ón
del proyecto
<
z

5>
z
::>
Director .5
ü
ejecutivo <
o
z
::>
u..
Gerente Gerente Gerente Director de

fu ncional funcional funcional directores del proyecto
r... ---~=~:1-- ------- ---~:~~~----------- ----~:-n~~------------c~:::~~:~:;::~-,,

---------------- ----------------------------------------------------------,-------------,
. :}
......... r. ......... (las casillas azules representan al personal Coordinación
CoordinaC1on que part1apa en las actlVldades del proyecto) del proyecto A
del proyecto 8
Figura 5.18: Estructura organizacional mixta o compuesta.
Las organizaciones más modernas comprenden todas estas estructu ras a distintos
niveles, como mues tra la . Por ejemplo , incl uso una organizac ió n

FUNIBERf~ ...................................................
HERRAMI ENTAS Y TÉCNICAS DE GESTIÓ N DE PROYECTOS
fundamentalmente funcional puede c rea r un equipo especial pa r a dirig ir un proyecto

concreto. Ese equipo puede reuni r muchas de las características de un proyecto en una
organización por proyectos; puede incluir incluso personal proveniente de d iferentes
depa rtamentos funcionales, pued e desa rro lla r sus propios procedimientos operativos y
puede funciona r fue ra de la estructura normal en lo relativo a información.
5.2.3 PLAN DE PROYECTO
La planificación culmina con el plan del proyecto. Este documento describe el enfoque
completo para desarrollar la aplicación e -Business y sus sistemas informáticos
com ponentes. Es un documento que informa a la gestión, a los miembros del equipo y
al cliente . Es como un mapa que sirve pa ra guiar al proyecto y sus involucrados.
El plan del proyecto es un documento forma l y aprobado que se utiliza pa r a di r igir y

cont rola r la ejecución del proyecto. Debe ría ser distribuido según defina el plan de
Gestió n de Comunicaciones (po r ejemp lo, la di r ección de la organización ejecutora
puede necesitar un plan general con pocos detalles, mientras que un contratista puede
necesitar muchos detalles de un solo tema). En algunas áreas de aplicación, se usa el
término plan integrado del proyect o para refe rirse a este documento.
Debe establece rse una clara distinción entre el p lan del proyecto y las bases para medir
la r ealización del proyecto. El plan del proyecto es un documento o conjunto de
documentos que debería esperarse que cambien a medida que haya más información
disponible sobre el proyecto. Las bases p ara la evaluación de la realización del proyecto
representa un control de dirección que normalmente só lo cambiará interm itentemente y
en estos casos, los cambios serán realizados únicamente como respuesta a un cambio
autor izado del alcance del proyecto.
En este documento se especifican aspectos de desarro ll o, los subproductos a entregar ,

requerimientos de recursos , programación , responsab il idades organizac ionales y
presupuestos, y el proceso de gestión. Además, incluye facto res de riesgo y estrategias
de gestión del riesgo , y describe de q u é manera se gestiona y asegura la calidad.
Establece el coste y las bases de la programación para gestionar y controlar el proyecto.
Además en sí mismo es parte efectiva del sistema de contro l del pro yecto.
Hay muchas maneras de organizar y presenta r el plan del proyecto , pero normalmente
incluye lo siguiente (estos puntos se describirán con más detalle más adelante ):
• Justificación del proyecto .
• Descripción de los puntos de vista o estrategia de la dirección del pro yecto (u n

resumen de los planes de dirección para cada una de las otras áreas ).

HERRAMIENTAS Y TÉCNICAS DE GESTIÓN DE PROY ECTOS
FUNIBERff
• Establecimiento del alcance , que incluye las entregas y objetivos del proyecto.
• WBS al nivel al que se realiza rá el control.
• Estimación de costes, fechas programadas de ini cio de actividades y asignación de

responsabilidades al nivel de la EDP, en el que será ejercido el cont rol.
• Bases para la ev aluación de la rea lización del proyecto en cuanto a programa y

costes .
• Principales hitos y fechas objetivo para cada uno.
• Personal requerido o clave.
• Riesgos clave, in cluye ndo las restricciones y supuesto s y las respu est as previst as
para cada uno.
• Planes auxiliares de dirección, incluyendo el plan de gestión del alcance del

proyecto , el plan de dirección del programa , etc.
• Temas abiertos y decisiones pendientes.
Se deberían incluir otros resultados de la planificación del proyecto en el plan fo r ma l,

basándose en las necesidades de cada proyecto en particular. Por ejemplo , el plan del <
;;¡
<
proyecto para un gran proyecto incluirá , normalmente, un organigrama del proyecto . t:
Vl
:3
:':
z
Para probar la adecuación de l plan , el gestor del proyecto debe preguntarse : ::>
z
·O
ü
<
o
¿El plan perm ite gestionar el proyecto de forma adecuada? z
"
u.
Q
¿El plan provee información suficiente para que los miembros del equipo
plan ifiquen y ejecuten su trabajo?
¿Se cuenta con el compromiso de la dirección y del equipo del proy ecto?
Un patrón de plan se entrega en el Apéndice 111.
5.2.4 INFORME DE ALCANCE
El Informe del Alcance constituye una base documentada para la adopción de las
futuras de ci siones del proyecto y para confi r mar o desarrollar entre las entidades
inv olucradas en el proy ecto aportando un entendimiento común del alcance del mismo.
Según progresa el proyecto , puede ser necesario re v isar o depurar el informe del
alcance, para reflejar los cambios en el mismo. El informe del alcance debe inc luir, bien
directamente o por referencia a otros documentos, lo siguiente:

FUNIBER~ . . . . . . . . . . . . . . . . . .ma. . . . . . . . . . . . . . . . . . .. . .
• Justificación del proyecto : la necesidad del negocio que debe ser resuelta po r el
proyecto. La justificación de l proyect o co n st itu ye la base pa ra la evaluación de
futuros compromisos.
• Producto del proyecto : un breve resumen de la d escripció n del product o.
• Entregas del proyecto : una lista a modo de resumen de los subproductos cuya
completa y satisfacto r ia ent rega marca la finalización de l proyecto . Po r ejemplo , las
principales entregas de un proyecto de desa rrollo de software pueden incluir el
lenguaje de trabajo del ordenado r, un m anual de usua rio y un gesto r del prog rama
interactivo . Cuando sean conocidas, las exclusiones deben ser identificadas,
teniendo en cuenta que cualquier cosa no incluida explícitamente es implícitamente
excluida.
• Objetivos del proyecto : los criterios cuan t ificables que deben cumplirse para que el
proyecto se considere un éxit o. Los objetivos del proyecto deben incluir, al menos ,
medidas de costes, programa y calidad . Los objetivos del proyecto debe tener un
<
z atributo (por ejemplo, coste), un p atrón o un idad f undamental (por ejem plo , dólares
<
~
"'~ USA) y un valor absoluto o re lativo (po r ejemplo, menos de 1 , 5 millones). Los
<
o objetivos no cuantificables (por ejemp lo , la satisfacción del cliente) constituyen un
.,~
<
riesgo elevado.
"'<
1-
"'~ En algunas áreas de aplicación , las entregas del proyecto son llamadas objetivos del
>
z
::::> pr oyecto mientras que los objetivos del proyecto son llamados factores críticos de
z
o
ü éxito.
<
o
z
::>
"-
'º 5.2.5 ÜTRAS HERRAMIENTAS
5.2.5.1 Diagrama de Ishikawa o Espina de Pescado
El Diagrama de lshikawa, también llamado diagrama de causa-efecto, se trata de un

diagrama qu e por su estr uctura ha venido a llamarse también: diagrama de espina de
pez/ pescado. Fue concebido por Kaoru lshikawa en 1943.
Este diag rama consiste en una representación gráfica sencilla en la que puede verse de
manera relacional una especie de espina central, que es una línea en el plano horizontal,
y represe n tando el p r oblema a analiza r , a su derecha. Es una de las diversas
herramientas surgidas a lo largo del siglo XX en ámbitos de la industria y posteriormente
en el de los servicios, para facilitar el análisis de problemas y sus soluciones en esferas
como lo es la calidad de los procesos, los productos y los se rvicios .
DIRECCIÓN Y GESTIÓ N DE PROYECTOS TI C 30 3

HERRAM I ENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
FUNIBERfJ
Su uso en proyectos es muy relevante para clarificar y buscar l as causas de los

problemas y así organiza r acciones preventivas y re activas.
La sigu iente figura muestra la estructura bás ica de este diagrama. Para un problema
conc r eto , se identifican sus posibles causas por áreas (en este caso 6 áreas
estándares). Cada causa sigue siendo analizada buscando sus causas. Cada caus a se
coloca en una línea y así sucesiva mente .
causa Efecto
Hombre Máquina Entorno
... .. ... ...

-e ... ... ...
... ...
..
...
..
..
...
. ...
....
-e J Problema
<
z
<
~
::¡
:E
Subcausa ... <
o
... ~
<
causa principal ... ... o:
... ....<
Vi
::¡
>
Material Método Medida z
=>
z
·O
ü
<
e
z
::>
"-
Figura 5.19 : Estructura básica del Diagrama de Ishikawa.
º
El proceso especifica que el problema es la cabeza y sus causas se agrupan en una
columna ve rtebra l. Ver siguiente fig ur a . A l o largo de la co lumna vertebral las
agrupaciones por área se ilustran como esp inas principales dentro de las cuales se
añaden espinas o causas y dentro estas espinas menores o causas de causas. Este
proceso se repite ite rati vamente hasta llegar a las causas iniciales o fundamentales.

HE RRAMI ENTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
Espina principal Espina Espina principal

menor
... "' Espina

•
Columna Espina
vertebral
menor ...
• •
___.
• --
•
----
• .,.
CABEZA
...
•
Espina principal Espina prinapal
Figura 5. 20: Estructura de llenado de un Diagrama de Ishikawa.

<
z
<
~
~
:r
<
La siguientes figu ras 12 muestra n ejemplos de aplicación del Diagrama de lshika w a.
o
..
~
"
::" Sistema de
¡¡; Capacidad
[!: recompensas
>
z
::;)
z Ob1etivos Conoom1ento
·O
u Claridad
<
o
z
Contratación
;;:. I nterdependencia Ayuda
Congruencia Capacitación
Mediciones Escuchar Habilidades
Tiempo
Confianza
Veracidad I nterrelaciones
Evaluación
Honestidad
Oportunidad E1emplo Educación
Observación Liderazgo Valores
Formación Integridad
Figura 5. 21 : Ejemplo de Diagra ma de Ishikaw a .
12. Fuentes:
INDA CUNNINGHAM, ARTURO. (2000). Una guía para el mejoramiento de la calidad en la pequeña y mediana empresas,
basada en el método de W. Edwards Deming. OEA. P. 130. Fig. 6. P. 64.
Enlace web: "ti;¡ . N I'> . .. sc1ence.cas ore OEA GTZ. LIBRO S E1. MAPA ca:3 niaoa " i ':l
DAVIDV. (2011). El diagrama de Ishikawa.
Enlace web: ~tto: r de .1d, d1970 ... crdore<s com'2011 /04'2E'd1ag'a'r.a-¡: e-·s" ' ª' e
SEGJU R. Enlace web: hri:p . /wMv.doc~touorr DocslDocunent-Detail- Gooo e.asnx?doc •d=4777SQ45

FUNIBER~
1nfrac:stn.Jct1Jra ttenam~ntas
enorme oroóeeuadas
lntern.1t>OOOeS
Falta
contTol
t..:atuQk?za f\a~uralcza oc la
de )il...-a a~qu1tectura B< Med>OS
l'omw.i<>n 1na:lecuados falt.>n Perdoda oe No ?rotecoorusmo
ansuftoente ~ iJlol•·llou saber ~1f tecn<O
·roo·
Oesc.OClOOmiento De5cotioc1mtento
hnoone> CS N~ITT
Confloctoo lmooc;tOf""'90' l:isufoe.ente

oe opinión desconooóos p!arufcaoo.,
gostión
Farta de de camt>os uso de ata¡os <
SlAs S.. mea~ z
<
antes si vov en
MUC'>OS
consumen
mucho t>cmpo
~ C...¡.ss
nt9'as pe=na
NoSt:l<oeNs.guen
"e;
;¡:
<
o
..e;
Fata
Figura 5.22: Ejemplo de Diagrama de Ishikawa.

FUNIBER~
HE RRAMI ENT AS Y T ÉC NI CAS DE GE STIÓN DE PROY ECT OS
. . . . . . . . . . . . . . . . . . . . . . . .m53. . . . . . . . . . . . . . . . . . . . . .- -
..
....__ .. ,...,.• •"""CN#lf'~
....,..-.,-~~
"""" .. ~.l'I('
,,..._ .. l"""'
~ SeJ'.I! :?JS
~ ~ ltblv;'IO~'O.o>...OU,~
-- ---
l~ ·1-oa--~Jl.r'Ou"•Ol''"A ..
..«tO't'\Ot CAl:l!I. ~*"- ~ ..._ f'~~v,....,~Miie"'
pr4t'lr~ ~·-~ .. 0.:.t.w.arr ... "'{~(~.~~
~... • nbdo ""~"' .... '"'X!PWllXI' ....
~~-~ ·~X-C""Oti
-- l)JJ 1•~
__......
....
...
·--
.......
_~
<
z
t~~·
- _............
<
:!
"'"'<
"
o
"'
w
"'
<
;;;
"
V>
~
z
Figura 5.23: Ejemplo de Diagrama de Ishikawa.
::>
z
o
~ 5.2.5.2 Qua!ity Function Deployment (QFD )
z
"
u.
El despliegue de la función de calidad (o QFD, por sus siglas inglesas) es un método de

diseño de productos y servicios que recoge las demandas y expectat ivas de los clientes
y las traduce, en pasos sucesivos, a características técni cas y operati vas satisfactorias
o, en otras palabras, traducir las actu ales declaraciones y necesidades del cliente (" la
voz del cliente") en acciones y diseños para construir y entregar productos de ca lidad.
La filosofía del Despliegue en función de la calidad (QFD ) fue iniciada por Yoji Akao y
Shigeru Mizuno.
Las herramientas y técnicas típicas usadas dentro del QFD inc luyen:
• Diagramas de afinidad. Pa ra emerger la "estructura profunda " de los requisitos

expresados del cliente.
• Diagramas de relaciones. Para descubrir prioridades y causas raíz de problemas de

proceso y de requisitos no expresados por el cliente.
• Árbo les de jera rquía. Para comprobar si hay datos faltantes u otros propósitos.
DI RECCIÓN Y GESTIÓN DE PRO Y ECT OS TIC 3 07

H ERRAM I ENTAS Y TÉCNICAS DE GE STIÓN DE PROYECTOS
FUNIBER
• Varias matrices. Para documentar relaciones , priorizaciones y responsabilidades.
• Diagramas de proceso de programas de decisión. Para analizar fallas potenciales de

los nuevos procesos y servicios .
• Proceso analítico de jerarquía . Para dar la prioridad a un grupo de requ isitos, y

seleccionar de entre las alternativas posibles para satisfacer estos requisitos.
• Blueprinting . Para representar y analizar todos los procesos que están implica dos en
el aprovisionamiento de un producto o servicio .
• Casa de la cal idad.
El elemento central del m étodo QFD es la elaboración de la matr iz Necesidades /

Expectativas de los clientes - Reque rimie ntos del producto. Esta matriz se conoce en
términos de gestión como matriz de planificación, matriz QUÉ-CÓMO , o coloquialmente
como Casa de la Calidad (por su forma visual). Esta matriz transforma las opiniones de
los clientes , debidamente ponderadas, en especificaciones técn icas, y define así el
producto. Los deseos del cliente - denominados QUE en la jerga del QFD - se
materializan en las características del producto , los COMO. La siguiente figura muestra
un ejemplo de QFD desplegada de la fabricación de aparatos de medición eléctrica que
permite compara r los productos de las empresas ABB y SIEMENS 13 . <
a:
<
;;;
~
~
z
::>
~
z
o
u
Correlaciones~
<
o
!!;
---1
ü:
Cómo
3 ( 4 '\
tO e:: ft)
ü · O .:!:
e:: -~ ~
Que· .':!
0
Relaciones ::> ~
a. ~ E
wºu
lli_~_
5 Cuánto
Evaluación de las
6
características de control
Importancia
7
técnica
Figura 5.24: Ejemplo de QFD.
13. UNED. Tres herramientas para la concepción de nuevos produdos. Textos de Ampli ación UNED.
Enlace web: .., r"". ;;. ~"'"'e < • -hr: 0 C'e~ --o 3C!C",, _,..,..o og ca mod 1 ,e,,.,c:! am. ~,.. c~5.htr-

HERRAM I ENTAS Y TÉCNICAS DE GESTIÓN DE PROY ECTOS
FUNIBERff . . .11m1. . . . . . . .. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ._ _
En el QFD se diferencian dos partes: el diseño de la Casa de Calidad , y el anális is o

lectura de la matriz. El propósito de esta matriz es trasladar las neces idades de l cl iente a
las características de las actividades del proceso , las cua les serán desp legadas a t ravés
del diseño del mismo. Para completar la matriz se requieren de ocho pasos 1 4 :
• Paso 1 .- Definir requerimientos de calidad en términos del cliente. (QUÉ ' s)
• Paso 2.- Enunciar las actividades del proceso. (CÓMO ' s)
• Paso 3.- Crear la matriz de relaciones entre los QUÉ · s y los CÓMO' s.
• Paso 4.- Análisis de cómo nos ven a nuestra organización y a la competencia.

(Ev aluación competiti v a)
• Paso 5.- Objetivos de las activ idades del proceso (CUÁNTO)
• Paso 6.- Evaluación de los objetivos de las característ icas de ca li dad de las
actividades del proceso.
<t
z
<t
u • Paso 7 .- Importancia técnica o relativa de las activ idad es del proc eso .
"'~
<t
o • Paso 8.- Matriz de correlaciones entre CÓMO ' s.
~
Cada paso permite ir completando la matriz tal como ilustran la s sig uientes f iguras 15 .
14. RUIZ, RI CARDO. (2011 ) . Cómo elaborar un QFQ.

Enlace web: http: ' ricardo[Jizdeacana bloospot.com/20111 OS1gfd-u11a-herram.e1ta-para-a J'near. ntrr:I
15. ALQFD. Herramientas de QFP. Asociación Latinomericana de QFD.
Enlace web: http: 1\ww.ofdl2t.rn...., Herrarniertas OFD/herram1emas ofd.ht'11 i
QFDI. QFD Inst itute. En lace web: http·11www gfdi.ora'
QFDOnline. Enlace web: bttp: 1\ "11".ofdonline.comr
DIRECCIÓ N Y GEST IÓN DE PROYECTOS T I C 309

FUNIBER~
HE RRAMIE NTAS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
..... -. .. .
,.. .,. ._ ___ ., _____ -: :·-··
-, ~~~~
~ Co-rr
-e-
la_
d_o-
nes~~~~~
=--- --- / --;....--·· .. - ..

.- ,;_ .:..
1
- ·- J Cómo(s) : i·
:¡
··-
_.;.
1 ~ "2
RI
e

11
Qué(s)
1
~
Relaciones e~
o
E
•O
u o
~
RI
ci
E
31
~
:i...
u
1
-
'
. 1
.. - -
Indicadores
•r ; ¡
·~I__,.~~~~~Có_._m_o_n_o_s_ve_m_o~s~~~~~-.--'.1; <
• 1
____D_ifi_rcu_lta_d_p_a_ra_rea_l_iza_r_e_lse_rv_ia_·o_ _ _~L~
J~
z

z
:::>
z
·O
ü
<
"::>z
....
º
310 DIRECCIÓN Y GESTIÓ N DE PROYECTOS TIC

HE RRAM IENTAS Y T ÉCNIC AS DE GESTIÓ N D E PROYECTO S
·- • ABB
] Siemens
Corre_lac.ion~
Positiva
Dirección de la Mejora .. .. ..
..... N M V
o o Percepciones
Negativa u 8 8 .!.!
·e:u 6 ·¡::
u 6
del cliente bueno
•QJ •CJ •QJ ro ~
1- 1- 1-
•QI
1- ·o
Relaciones e
.9 o .9 o ro
Fuerte __.. 5 e(l) e:Si e e 1::'.
.E .9! 8.
QJ
Media ~ 3 E E E
e E
Débil ~ 1 5::> •t :::;¡
§
::>
QJ
:::;¡
CT
QJ g- CT
CI 8" 1 2 3 4 5
o:: o:: o:: o::
1.1
1.2
•
..•
t
voz 1 1.3 •!...:::; _ _
1.4
Necesidades .. +
1.5
< del chente ---- - ----
:••
z
<
u 2. 1
VOZ 2
~
:¡:
2.2 T ._
<
o 3.1
VOZJ
"'
~
3.2
... . !_,_____
. --.-
"' ~
"'~
::z
Análisis
de la
competencias
o
"(ij'
¿:
3
2
+. -
:::;¡ 1
z
·O Ob;etrvos operacionales (Targets)
ü
< Peso de la columna
"::>z
"-
Figura 5.26: Pasos de construcción de la matriz de Necesidades/ Expectativas, matriz de pla nificación o Casa
de la calidad.
T al como explícitamente señala Benvenuto (2008 16 ) en el procedimiento del QFD deben

participar distin t os departamentos de la organi z ación , tales como marketi n g ,
producción, control de calidad , servicio al cliente , 1+ D, entre ot ros. Lo normal es que el
equipo encargado de desarrollar el QFD se encuent r e integrado po r c i n c o a oc ho
personas; además, debe tener un líder, el cual será el moderador. Este últ imo debe te ner
conocimientos sólidos sobre el uso de este método.
El procedimiento completo del OFD abarca cuatro fases , en las cuales se utiliza una
matriz QUÉ-CÓMO para cada una de estas fases.
16. BENVENUTO, RENZO. (2008) . Diseño de un proceso basado en la metodologfa del QFD para el desarrollo de productos en
una empresa de asistencias internacionales. Universidad Peruana de Ciencias Aplicadas. Perú.
En lace web: htto:/. cvbertesis.upc eou.pe upc/2008lbenvenuto hrlr.t m1 ~dx ben \'e'lL ~ o hr. l:tml

H ERRAMIENTAS Y TÉ CNICAS DE GEST IÓN DE PROYECTOS
FUNIBERff
• La primera fase es la planificac ión del producto , en la cual se relacionan y evalúan

los requisitos del cliente (los qués), para luego ser traducidos a las características
técnicas de diseño del producto (los cómos ), dándonos como resultado las
especificaciones del diseño. Se acota a nivel de referencia , que el mayor campo de
uso de QFD es hasta esta fase y es donde más se encuentran ejemplos de matrices
de planificación.
• La segunda fase es la planificación de la calidad de los componentes, en esta fase,

se realiza una traducción de las principales car acterísticas del producto (los qués )
en características de calidad para cada uno de los componentes del producto (los
cómos) .
• Luego, sigue la tercera fase : la fase de planificación de la calidad del proceso . En

esta fase , se realiza una traducción de las características críticas de los
componentes (los qués) en características del proceso (los cómos); es de cir se
busca identificar las distintas fases importantes del proceso para obtener las
características deseadas para el producto .
<
z
<:
u
• La cuarta fase : la planificación de la calidad de la producción. En esta fase se ~
>:
<
traducen las características crít icas del proceso (los qués) en instruccio nes de o
~
producción y de inspección de calidad (los cómos ), esto con el fin de delimitar "'
<
;;¡
tolerancias y metodologías de con trol para mantener la va riabi lidad del producto ....<
;;;
dentro de los rangos de control deseados . ~
>
-á
u
<
e
z
::>
u_
(Q·
312 D IRECCIÓN Y GESTION DE PROY ECTOS TIC

FUNIBERff ......................................................
Plan1ficaoon de
l:>s componentes
Caracteristicas de
IOs aimpcnentes
Planificaoon del proceso
Caracterisbcas Carac:tensocas
crioc:as de los del proceso
componentes
<
z
<
~
~
"<oa:
..
u
:::a:
<
....
¡;;
~
>
z lnstrucoones de
:::;, trabajos y controles
z
·O
~
o
z
:o
L1.
Figura 5.27: Pasos de construcción de la matriz de Necesidades/ Expectativas, matriz de planificación o Casa
G
de la Calidad.
El control es una etapa de valoración del trabajo realizado buscando aprovechar buenas
prácticas y analizar las debilidades del proyecto e-Business toma ndo de referencia los
dat os recogidos durante el seguimiento.
5.3.1 ASEGURAMIENTO DE LA CALIDAD
El aseguramiento de la calidad (Ouality Assurance, QA) asegura que el producto cumple

con los requerimientos y provee la funcionalidad y calidad deseada.

FUNIBER
La ca lid ad, como los requerimientos de desempeño técnico, debe ser especificada en
términos cuantitativos que claramente compren sibles por el cliente y los miembros del
equipo . Además , mientras el equipo se compromete a construir la calidad en el
producto , una práctica frecuente es contar con alguien dedicado y separado del equipo
cumpliendo funciones de asegurador de calidad.
El principal propósito del aseguramiento de la calidad es detectar errores y corregirles

rápidamente. La detección y corrección t emprana puede resultar en benefic ios de coste
y tiempo significativos. De hecho, el coste de correg ir errores en la etapa de diseño es
un 10 % de corregirle en la etapa de prueba.
La herramientas básicas para el aseguramiento de la calidad son las re v isiones técnicas

y las pruebas. Las revisiones técnicas son efectivas cuando encuentran defectos
tempranamente y encuentran diferentes tipos de erro r probar. La s prácticas más
comunes de aseguramiento de la ca l idad los walkthroughs , las inspecciones y las
pruebas.
<
z
<
u
Ambos tipos de revisiones son efectivas para la detección temprana de errores en §
:!:
<
requerimientos , interfaces, diseño , codificación o manufactura , y documentación . o
.e¡
<
El seguimiento del proceso de calidad, requiere métricas precisas. Por ejemplo , dos
métricas usadas habitualmente en el desarrollo de software son:
-
;;:
<
""''
• Densidad de defectos (número de defectos por 1 .000 líneas de código fuente).

<
o
z
::>
• Eficienc ia de remoción de defectos (porcentaje de defectos remo vidos en una u.
operación: revisió n de código o una prueba) .
a.- Walkthroughs
Un walkthrough son reuniones info rmales en la que los miembros del equipo revisan el
diseño o código para identificar mejoras y problemas.
b.- Inspección
Las inspecciones son revisiones más formales donde revisores usan listas de chequeo
(checklists) para estimular la re visión y recurren a registros de control y
retroalimentación sistemática para mejorar el proceso de desarrol lo.

FUNIBERf~ .....................................................
HERRAMIENTAS Y TÉCNICAS DE GESTIÓN DE PROYECT OS
c.- Prueba
La prueba es medio más común de asegurar la calidad. Es el ejerc 1c10 sistemático de
buscar y detectar defectos donde lo fueron hallados anteriorment e. Conducidos e nivel
de unidad y de sistema, sirven para verificar la funcionalidad y ca li dad de l sistema.
5.3.2 T IEMPO Y COSTE
a.- Proceso de control del proyecto
El propósito del control del proyecto es:
• mantener el proyecto en curso y cercano al plan de trabajo ;
• identificar problemas antes de que ocurran; e,
<
z • implementar planes de recuperación antes que los daños sean irreparables.
:
<
o El proceso involucra comparar el progreso con el plan y tomar accio nes correctivas
~ conforme existan desviaciones que afecten el desempeñ o y / o el plan; y pro veer
retroalimentación ( ).
Planificar y Replanificación si se necesita

organizar
Medir y evaluar
desempeño
..
Desv1acrón
Ejecutar trabajo
..
Control de desempeño
AJustar métodos de trabajo
Figura 5.28 : Control del proyecto.
Para un control a tiempo y efectivo, el gestor del pro y ecto debe t ener completa
vi sibil idad del a van ce del proyecto. Pa ra ello , se debe efectuar u n m onitoreo y
seguimiento sistemático.

FUNIBERf~
H ERRAMI ENTAS Y TÉCNICAS DE GEST IÓN DE PROY ECTOS
El grado de formalidad y frecuencia de monitoreo depende del tipo de proyecto, aunque

siempre debe enfoca rse en el coste , programación y desempeño técnico.
b.- Control del coste y del programa
El seguimiento del coste y de la programación involucra comparar el estado actual

contra lo presupuestado en cuanto coste , tiempo y etapas.
Desviaciones significativas del plan requieren atención prioritaria del gestor del proyecto
para tomar una acción correctiva a tiempo. Conocer la desviación no es suficiente , hay
que identificar la causa del problema. Si la desv iación del plan es grande, se debe decid ir
si se replanifica .
Para tener visibilidad de estas decisiones, el coste y la programación son analizados de

forma integrada. Estar dentro del presupuesto no es suficiente si las tareas no se
completan a tiempo. Similarmente , completar tareas de acuerdo al programa no basta si
los costes "se han disparado". En este análisis, disponer de la W BS provee la base <
z
fundamental para compara r coste y programa contra el plan . "u
~
z
<
o
ffi
c.- Valor ganado C)
<
"'....<
Aunque las cartas GANTT y los informes de acumulación de reportes proveen "'ffi
>
indicado res útiles del estado del proyecto , presentan limitaciones. La limitación primaria z
::;¡
es que son complejos y difíciles de analizar, particularmente para grandes proyectos con z
~
u
muchas tareas . Esta complejidad puede conducir a una percepción distorsionada del <
o
z
::>
estado del proyecto. Una técnica para proveer una mejor, más holística visión del u.
progreso del proyecto es la técnica del valor ganado (Earned Va lu e Technique ).

Originalmente creada para un mejor seguimiento de proyectos gubernamentales a gran
escala , es hoy en día herramienta habitual en los proyectos informáticos.
La técnica mide el valor del trabajo realizado en términos del presupuesto asignado al
trabajo . Permite separar las variaciones de coste y programación en términos
monetarios .
La variación en coste se debe a la v ariación en el precio del trabajo realizado m ientras la

v ariación en la programación se debe al trab ajo real izado fuera de los tiempos
programados.
El valor ganado y las variaciones son calculados para una actividad simple , un gru po de
act ividades o el proyecto completo . De las v ariaciones de coste y programación es
posible dete rm inar indicadores de desempeño de coste y programación del proyecto.
Estos índices proveen visibilidad instantánea sobre el desempeño del proyecto . Esto
ayuda al gestor del proyecto a estima r el coste para terminar y el coste actual a la
fecha , basado en el desempeñ o a la fecha.
316 DIRECCIÓN Y GESTIÓN DE PROYE CT OS TIC

FUNIBERf~; .................1:._.ac_._......_._._._.__
La técnica se basa en tres parámetros básicos:
- Presupuesto planeado (planned budget): coste presupuestado de trabajo

planificado (budgeted cost of work schedu/ed, BCWS).
- Coste actual: cost e actual de t rabajo realizado (actual cost for work performed,
ACWP).
- Valor ganado (earned value): Cost e presupuestado de t rabajo real izado

(budgeted cost far work performed, BCWP).
Variación del coste (cost variance, CV) se calcula de la siguiente manera:
- CV = BCWP - ACWP
- Una variante negativa indica un coste excesivo.
Variación de la prog ramación (schedule variance, CV) se calcula de la siguiente manera:

<
z
<
u
~ - SV = BCWP - BCWS
~
o
"'
~
"' Una va rianza negativa indica que el proyect o esta fuera de programación.
<
;;;:
<
!:
"'e¡ Ambas va ri anzas son expresadas en términos monetarios , pero también pueden
>
expresarse en porcentajes de la siguiente manera:
3
~
V
<
o % cv CV / BCWP
5
1...
""": % sv SV / BCWP
El índice de desempeño de coste (cost performance index , CPI) está calculado como:
- CPI = BCWP / ACWP
El CPI puede usarse para calcular e l coste de l proyecto o el coste estimado al

completarlo (estímate at completion, EAC) . Una fó rmula simplificada pa ra EAC es:
EAC = BAC / CPI
- donde BAC (budgeted cost at completion) es el coste básico o presupuestado

para terminar el proyecto.
Similarmente , es posible calcular el índice de desempeño de la programación (schedule

performance index, SPI ) de la siguiente manera:
- SPI = BCWP I BCWS

FUNIBER
Por último , una vers1on simplificada para estimar la duración del proyecto o tiempo
estimado para terminar el proyecto (estima ted time to comp/etion, ETC ) se puede
calcular de la siguiente manera:
ETC = OD ! SPI
donde OD es la duración original (original duration, OD).
d.- Revisión
d . 1.- Encuentros de re visión
Encuentros de re visión son instrumentos vitales en el control del proyecto. El propósito

es va loriza r el progreso e identificar áreas de desviación desde el plan para proponer
acciones correctivas. Los encuentros son el mecanismo para discutir abiertamente
problemas presentes y futuros y proveer un marco de comunicación habitual, si se
desea.
<
z
Los encuentros: ...,<
;;:
~
<
o
- Proveen visibilidad a los planes y su progreso, y crean oportunidades para "'
w
"'
obtener y reforzar compromisos con los participantes. <
"'<
¡¡;
Son más efectivos cuando ellos son programados a intervalos regulares ~
>
(semanalmente es lo habitual) y sig ui endo una agenda establecida y acordada :5
por los involucrados. ...,
<
o
z
Deberían contar con la presencia de personas representativas de las áreas c.
involucradas para tener respuestas adecuadas, negociar soluciones y hacer
compromisos.
Son diferentes de una revisión técnica y / o de calidad, donde se dedica especial

atención a detectar y co rregir problemas más que revisar el progreso.
Son diferentes de una reunión de gestión o de dirección , donde el gestor de

proyecto se reúne con un directivo o un comité de dirección, para informar del
proyecto y su integración en la estrategia organizacional.
d .2 .- Infor mes de estado
Los informes de estado son preparados y enviados de forma regular para informar a las
personas externas a la organización. Ellos deben ser cortos y oportunos.

FUNIBER~1; a-.------------BEl:mml_______________
HE RRAM I ENTAS Y T ÉCN I CAS DE GESTIÓN DE PROYECTOS
d .3 .- Agenda del proyecto
Una agenda típica incluye:
- detalle del prog re so programado (prin cipales hitos, programa y costes) ;
- avance de actividades específicas;
- estado de determinados ítems y /o recursos;
planificación futura; y,
- estado de las áreas de alto riesgo.
d.4.- Informe de alcance e informe de realizaci ón
Es conveniente mantener actualizado el informe del alcance con el fi n de mostrar los

cambios al plan del proyecto . Las nuevas ve rsione s del info rme de alcance deben ser
<
z mantenidas en la biblioteca del proyecto y los cambios y alteraciones ser gest ionadas de
:
<
;:w
e
Aparte y vinculados al informe de alcance están los Informes de Realización , los cua les
<
"'< organizan y resumen la información r eunida a lo largo del proyect o y presentar
V1
5> resultados de cualquier análisis. Estos informes deben proporc i onar los tipos de
:z
:::J información y nivel de detalle requerido por las distintas entidades involucradas, tal y
:z
·eu como establece el Plan de Comunicaciones.
<
e
z
...
::>
Q
5.3.3 DESEMPEÑO Y EVALUACIÓN
a.- Control de desempeño técnico
El control del desempeño técnico es el proceso de asegurar que todos l os

requerim ientos son satisfechos a través de revisiones de diseño .
a.1 .- Revisiones t écnicas
Estas re v isiones son usualmente mantenidas en los principa les hitos (po r ejemplo , al
término de las fases del c iclo de v ida) pero pueden hacerse en otros instantes.
El propósito de estas revisiones es mostrar el logro actua l o predecir objetiv os técn icos
potenc iales . El prog reso de los objetivos técnicos deber ía ha c erse c o n métricas
apropiadas.
DIR ECCIÓN Y G:: STJON D E PROY ECTOS TI C 319

FUNIBER~
H ERRAMIE NTAS Y T ÉCN ICAS DE GEST IÓN DE PROYECTO S
Una práctica útil de contar con representantes de los clientes en las re visiones técnicas
para asegurar criterios comunes de las necesidades y evitar sorpresas futuras.
a.2.- Métricas
Las métricas proveen visibili dad de lo conseguido y sus tendenc ias ofrecen un medio
predictivo para actuación futura. Ellas deben estar basadas en normas y estándares,
esencialmente cuant itativas, además de aco rd adas entre las partes.
b.- Cambio y control de la configuración
El control del cambio es un concepto simple , pero complejo en su detalle. Aún el

requerimiento mejor prep arado requiere cambios , especialmente cuando de software se
trata , una vez se diseña y se prueba.
Muchos proyectos fallan por cambios incontrolados que van más allá de los
requerimientos definidos inicialmente o acordados previamente. En va ri os casos
<
conducen a situaciones de escalada. Para ayudar a la detección y segu imiento del z
:3
cambio es esenc i al contar con un sistema de control de cambios que incluya "';¡:u
<
herramientas automatizadas , y un núcleo de gestión del cambio o grupo de contro l de o
a:
w
cambios. "'
::a:
<
¡-
Un sistema de control de cambios es un conjunto de procedimientos documentados y E

>
z
formales que definen los pasos a seguir para realizar cambios en los documentos :::>
z
oficiales de l proyecto. Incluye formularios , sistemas de seguimiento y los niveles de •!?
u
<
o
aprobación necesarios para autorizar los cambios . z
,¡:
En muchos casos, la organización ejecutor a tendrá un sistema de control de cambios

que podrá utilizarse tal cual para el proyecto. Sin embargo , si no tienen disponible un
sistema adecu ado, el equipo de dirección del proyecto necesitará desarrollar uno como
parte del proyecto.
Un proceso de cambio comienza con un r eque r imi ento de ca mbio , conocido en

ocas iones como una Propuesta de Cambio de Ingeniería (PCI , Engineering Change
Propasa!, ECP) , que identifica la necesidad de cambio , la naturaleza del cambio y el
impacto del cambio. Este cambio se remite al núcleo de gestión del cambio para que sea
revisado y se disponga su aprobación o no ( ).

HERRAMIENTAS Y TÉCN I CAS DE GEST IÓN DE PROYECTOS
FUNIBER f;
1
¡¡¡¡¡¡¡;¡¡;¡¡¡¡¡¡¡¡¡¡¡=::;~¡;;;;;¡;;;;:;¡=::::::s:¡:¡:::::==================m11:21
Valorar
.--- Originador
impacto
.;.
PCI
...1
Evaluar
PCI
...
Cumplim~ntar
cambio
¿!___ lAprobar?
-No Archivar
PCI
Verificar 1
cambio
Figura 5.29: Proceso de control de cambios.
<
"'< Los poderes y responsab ilidades de dicho grupo deben estar bien definidos y acordados
~
¡¡;
~
por las principales entidades involucradas en el proyecto. El núcleo, usualmente bajo
>
z
:::i
responsabilidad del gestor del proyecto o su designado se compone de representantes
z
e de cada área afectada por el desarrollo. Este equipo se diseña para que todas las partes
ü
o< compre ndan las consecuencias del cambio antes de hacerlas. En proyectos grandes y
z
::>
u.
complejos puede haber múltiples grupos de control de cambios con diferentes
responsabilidades.
Después de una revisión , el núcleo asegura que sólo los cambios aprobados sean
realizados de manera controlada y notificados a todas las partes in volucradas .
El sistema de control de cambios debe incluir tamb ié n p rocedimie ntos para realizar
cambios que pueden ser aprobados sin una revisión previa, por ejemplo, como resultado
de emergencias. Generalmente, un sistema de cont r ol de cambios p erm itirá la
aceptación " automática" de determinados tipos de cambios. Estos cambios deben ser
documentados y organizados de forma que no causen posteriormente pro blemas en el
proyecto.
c.- Evaluación del proyecto

La evaluación del proyecto es el proceso de valoriza r per ió dica m ent e de l estado del
proyecto con relación a sus objetivos. Esto difiere del control del proyecto en dos
aspectos:
D IRECCIÓN Y GESTIÓN DE PROY ECTOS TIC 321

HERRAMI ENTAS Y TÉCN I CAS DE GE ST IÓN DE PROY ECTOS
FUNIBER
El control del proyecto es responsabilidad del gestor del proyecto, la evaluación

es tarea de la dirección.
El control del proyecto es un proceso continuo, mientras la evaluación es

periódica.
Las evaluaciones típicamente son rea li zadas en hitos importantes para determinar
cuando cambios mayores han su rgido. Estos cambios pueden incluir re-valorización de
metas y objetivos , re-estructuración del plan o, aún mas , cancelación del proyecto.
Por último, la evaluación del proyecto juega un rol importante en la complexión del
proyecto. En este caso , evalúa experiencia pasada y desarrolla las lecciones aprendidas
para beneficio de futuros proyectos .
5.3.4 RECURSOS HUMANOS
a.- Motivación y construcción del equipo <

z
<
!::!
"'~
El desa rroll o y constru cción del equipo es una labor cubierta por literatura de ciencias y <
o
5
gestión del compo rtamiento (comportamiento organizacional, psicología social) pero a "'
<
menudo es muy ignorada en ambientes de desarrollo informático. "'
<
;¡;
e:
>
Muchos gestores de proyectos tienden a enfocar su atención en los detalles técnicos , z
:::>
ignorando que son personas las que programan y son personas las que usarán una "
-o
aplicación computacional. "'

<
o
:!'
,:
Pensar así hoy en día es un gran riesgo , pues muchos proyectos fallan por mal
funcionamiento del equipo y no por problemas técnicos . Las personas saben su trabajo ,
lo que saben es comparti r con otros , especialmente por prestar poca atención a las
personas y los grupos.
La construcción del equipo es el proceso de transformar un grupo de indi v iduos de

diferentes orígenes y formaciones en un grupo cohesivo de alto desempeño, con una
alta motivación y enfocados al logro de objetivos. Es un proceso que requiere
habilidades de liderazgo y una comprensión de los diversos factores organizacionales
que influyen en el trabajo en equ ipo y en las relaciones humanas.
A sí es necesario:
Compartir la visión y el objetivo. Una v isión compartida es esen cial para el éxito
del proy ecto, de hecho se le considera un factor de éxito . Estar de acuerdo en
la v isión y en los objetiv os ayuda a mantener el equipo centrado y producti vo.
En estos casos , la toma de decisiones es más efectiva y se evitan debates
efímeros y que sólo consumen tiempo.
322 DIRECCIÓ N Y GESTIÓ N DE PROYECTOS TIC

H ER RAMI ENT AS Y TÉCNICAS DE GESTIÓN DE PROYECTOS
FUNIBER
Compromiso con el proyecto . El compromiso puede definirse como el sentido

de lealtad y dedicación al proyecto. Miembros comprometidos desean dedicar
su tiempo y energía y hacer sacrificios personales por el proyecto.
La visión compartida es la base del compromiso. Sólo cuando las personas

comprenden y comparten una visión del proyecto, desean comprometerse con
el proyecto.
Gestores efectivos, trabajan duro para construir y afianzar el compromiso .

Buscan vías de crear posibilidades excitantes de conseguir un proyecto exitoso.
Crean ambientes de trabajo estimulantes, generando retos de trabajo
interesantes con oportun idades de crecimiento personal. In v olucran a las
personas en la toma de decisiones. Hacen visible el esfuerzo de cada persona
informando del progreso a cada miembro. Conv ierten a cada miembro en un
activ o de l proyecto.
Fuerte sentido de identidad. Miembro de equipos efectivos sienten que son

especiales , diferentes de ot ros. Este sentimiento de identidad el gesto r de
proyectos debe reforzarlo por todos sus medios a mano. Una práctica común es
<
z
usar símbolos v isibles para mostrar la identidad (distintivos en la ropa , las tazas
<
u
o:
de café , etc .) Probablemente la mejor manera es crear un sitio donde los
~ miembros compartan su trabajo. Hitos de celebración, o la pizza con cerv eza,
<
o
~
., son momentos de refo rzar el espír itu . Gestores exitosos crear y definen
culturas en sus proyectos , distintas del resto de la organización .
Con fianza mutua . Un equ ipo efectiv o requiere colaboración entre los miembros.
=>
La colaboración ex iste en climas de confianza. A mayor confianza , el equ ipo
z
o comparti rá mayor información , informará problemas y toma r á decisiones
ü
<
o
z
efectivas. Buenos gestores de proyecto crea r y nutren una atmósfera de
::>
u. confianza que a su v ez construye y refuerza la confidencialidad y el
compromiso. La confianza solamente existe en equ i pos hay valores de
honestidad y franqueza, donde las personas son tratadas con imparcia li dad ,
respecto y dignidad.
Miembros competentes . Gestores de proyecto ef ectivos reclutan personas

competentes , según las competencias que requiera el proy ecto . En este sentido
no deben ol v idarse que las habilidades de colaboración para el trabajo efecti v o
con otras personas son tan impo rtantes que las habi l idades y destrezas
técnicas . Un gesto r efectivo continuamente evalúa a su equipo y si empre está
dispuesto a cambiar o reasignar personas con un desempeño inadecuado.
Los gestores de proyecto gestionan re laciones con el resto de la organización y

remueven obstáculos. Los miembros se moti v an cuando ellos saben que la direc c ión
está comprometida con el proyecto y bu sca y pro v ee los recursos necesarios . Todo esto
requiere habi lidades de gestión superiores a las técn icas, que incluso pueden carecer y /
o desarrollar con el tiempo.
DIRECCIÓN Y GESTJON DE PROYECTOS TIC 323

H ERRAMIENTAS Y TÉCNICAS D E GESTIÓN DE PROYECTOS
FUNIBER
Entre las habilidades para construir un equipo, se cuenta:
Evitar comprometer lo s objetivos del equipo con intereses políticos.
Exhibir un compromiso personal a los objetivos del equipo.
No diluir el esfuerzo del equipo con muchas prioridades .
Ser equitativo e imparcial con todos los miembros.
Estar predispuesto a enfrentar y resolver problemas asociados con el desempeño

inadecuado de miembros del equipo.
Estar abierto a nuevas ideas e información proveniente de los miembros del

equipo.
b.- Resolución de conflictos
Los conflictos son parte de la vida diaria del proyecto . Ellos surgen desde cualquier <
z
<
involucrado en el proyecto , tanto puede ser de un miembro del equipo como de un ~
cliente o promotor. De hecho, la fuente de conflictos es abundante. "'

~
"<o
~
"'
La fuente más común es la competencia por los recursos escasos , las d ifere ncias
respecto de los objetivos y los medios para conseguirlos, y desacuerdos en costes ,
programación y tecnicismos . Por supuesto deben añadirse los conflictos que surgen de
la relaciones interpersonales .
Independiente de las causas, todo conflicto debe tratarse , identificando sus motivos y
orígenes , comprender sus causas y resolverlos de manera rápida. Fallar al hacer esto
puede seriamente alterar el proyecto y generar atrasos y gastos excesivos.
El c ierre comprende dos procesos y , según el tamaño del proyecto, el volumen de

información manejado y /o el grado de desorden sostenido , el cierre puede ser tan
complejo y extensi v o que puede considerarse un proyecto.
Además , en un proyecto e-Business cobra importancia el hecho que el cierre es una

etapa de recomendación y evaluación de lo aprendido .

--
FUNIBERÍ~ ............ .....................................
5.4.1 CIERRE ADMINISTRATIVO
El proyecto o fase, después de lograr sus objetivos o estar terminado por otras razones,
requiere su cierre. El cierre administrativo consiste en la verificación y documentac ión
de los resultados del proyecto para formalizar la aceptación del producto del proyecto
por parte de los patrocinadores o clientes.
El cierre incluye la recopilación de todos los reg istros del pro y ecto , asegurando que
reflejan las especificaciones finales , así como el análisis de l éxito y la efectivi dad del
proyecto y el archivo de esta información para su uso futuro. De hecho es importante
aprovechar esta info rmación para promover un aprendizaje.
Esto último no puede hacerse sin hacer una reflexión del trabajo realizado pa ra v er
cuánto se ha aprendido , qué se pudo haber aprendido , el po rqué de lo errores , etc .
Además es importante conseguir las aprobaciones finales del tra bajo realizado y del
<
z
~
< producto entregado.
~
:i:
<
o
~ Es importante hacer notar que las actividades de cierre administrati vo no deben
"'
< retrasarse hasta la term inació n del proyecto. Cada fase del proyecto debe ser
"'<
;;; apropiadamente cerrada para asegurar que no se pierde información útil e importante.
!>
z
:::>
z
o
ü
o<
5.4.2 CIERRE DE CONTRATOS
z
"
u..
Q
Es similar al cierre administrativo. Comprende la verificación del producto (¿ estaba todo
el trabajo realizado de forma completa , correcta y satisfactoria?) y el c i erre
administrativo (actualización de reg istros para reflejar los resultados fina les y el archi v o
de dicha información para su disponibilidad futura ).
Los términos y condiciones del contrato pueden esta blec er unos procedim iento s
específicos para el cierre del contrato.
Una terminación temprana del contrato es un caso especial de cierre del contrato.
DIRECC!ON Y GESTIÓN DE PROYECTOS TIC 325

FUNIBER
Fase de planificación. Se trata de establecer cómo el equipo de trabajo deberá satisfacer las restricciones de
prestaciones, planificación temporal y coste. Una planificación detallada da consistencia al proyecto y evita sorpresas que
nunca son bien recibidas.
Fase de ejecución. Representa el conjunto de tareas y actividades que suponen la realización propiamente dicha del
proyecto, la ejecución de la obra de que se trate. Responde, ante todo, a las características técnicas específicas de cada tipo
de proyecto y supone poner en juego y gestionar los recursos en la forma adecuada para desarrollar la obra en cuestión.
Cada tipo de proyecto responde en este punto a su tecnología propia, que es generalmente bien conocida por los técnicos
en la materia.
Fase de entrega o puesta en marcha. Como ya se ha dicho, todo proyecto está destinado a finalizarse en un plazo
predeterminado, culminando en la entrega de la obra al cliente o la puesta en marcha del sistema desarrollado,
comprobando que funciona adecuadamente y responde a las especificaciones en su momento aprobadas. Esta fase es
también muy importante no sólo por representar la culminación de la operación sino por las dificultades que suele presentar
en la práctica, alargándose excesivamente y provocando retrasos y costes imprevistos.
A estas tres grandes etapas es conveniente añadir otras dos que, si bien pueden incluirse en las ya mencionadas, es
preferible nombrarlas de forma independiente ya que definen un conjunto de actividades que resultan básicas para el
desarrollo del proyecto
<
o:
Fase de iniciación. Definición de los objetivos del proyecto y de los recursos necesarios para su ejecución. Las <
características del proyecto implican la necesidad de una fase o etapa previa destinada a la preparación del mismo, fase que ¡¡;
tienen una gran trascendencia para la buena marcha del proyecto y que deberá ser especialmente cuidada. Una gran parte "'
>z
del éxito o el fracaso del mismo se fragua principalmente en estas fases preparatorias que, junto con una buena etapa de ::>
z
planificación, algunas personas tienden a menospreciar, deseosas por querer ver resultados excesivamente pronto. -O
u
<
o
z
Fase de control. Monitorización del trabajo realizado analizando cómo el progreso difiere de lo planificado e iniciando las .._
:::>
acciones correctivas que sean necesarias. Incluye también el liderazgo, proporcionando directrices a los recursos humanos, ';'
subordinados (incluso subcontratados) para que hagan su trabajo de forma efectiva y a tiempo.

Los periodos generales de duración los podemos ver a continuación:
Nivel de
actividad
... Procesos de iniciación
Procesos de terminación
Procesos de planificación
Procesos de ejecución
Procesos de control
<
z
~
~ ... Tiempo
:r
<
o
~
"'
<
;¡: Figura 5.30: Curvas de procesos.
<
....
"'~
::z
:::>
z
~
V
<
o
z
:>
u.
?
D IRECCIÓN Y GESTIÓ N DE PROYECTOS TI C 327

FUNIBER f$ ============:::¡:;;;:================::::=:J
LJ Resumen
<
z

u..

Bibliografía
Bibliografía actual
[ 1J Al me ida et al. (2014). Gestao de Riscos em Proje tos: Urna Análise

Comparati v a da Norma ISO 31000 e o Gu ia PMBOK ®, 2012 . Re vista de
Gestiio e ?rojetos .
(2 ) Blé & col. , C. (20 10). Diseño ágil con TDD . safeCreative.
(3) Bossidy & Charan . (2014) . Ex ecution: The discipline of getting done.
Cro w n Bussiness .
(4) Carvalho , S. (2013). DNSSEC- Extensoes de seguranca para servidores
DNS . Curitiva , 1-36.
[5) Castro, F. R. (2013). O paradigma da orientac;:ao a objetos, a lin g u agem
unificada de modelagem (UM LJ e a organ izac;:ao e representac;:ao do
conhecimento: um estudo de caso de um sistema pa ra bibliotecas.
lnforma9fio & lnforma9fio, 82 - 1 05.
(6) Clausewitz, v. (2002 ). De la Guerra. LibroDot.com.
(7) Cosic & Shanks & Maynard . (2012) . To wards a Business Analytics
Capabil ity Maturit y Model. Geelong, 1 -11 .
[8 ) de Castro , M. J . (20 13) . Automa9§0 de Testes Baseados em Cenários com
UML e Programa9iio Orientada a Aspetos.
[9) Ev ans, A. F. (2014). Developing the UML as a formal modelling notation.
arXiv.
(10) Hills et al. (2013). Development of a Fourth Generat ion Pred ictive
Capability Maturity Model. Sandia Report, 4- 7 2.
(11 J lnsideCounsel. (2015 ). lnsideCounsel. Majority of companies lack policies
far in fo security. Recuperado de http: www .insidecounsel.com 201 5 1 O 2
3 majority-of-companies-lack-pol c es-for-info-secur
[12) it SMF UK . (2011 ). An lntroductory Ove rvi ew of ITIL 2011. ITIL.
(13] ITU and ABI Research. (20 15 ). Global Cybersecurity lndex and
Cyberwellness Profiles. Recuperado de https: \\v.\\ .itu. nt pub D-STR-SEC
U-2015 es
[ 14] Jacobson & col., l. (2000 ). El Proceso Unificado de Desarrollo de Software.
Madrid: Fareso .SA .
DIR ECCI ÓN Y GESTIÓ N DE PR OY ECTOS TIC 331

FUNIBER~
[ 15) Jurado J. L. M. & Pa rdo C. J. C , J. (2013). La gestión de proyectos

software, una prospectiva en la aplicación de est r ategias en la ingeniería
colaborativa. Lámpsakos .
[16) Linares N. P. & Piñero Y. P. & Rod ríguez E. S. & Pérez L. Q., L. (20 14).
Diseño de un modelo de Gestión del Conocimiento para mejorar el
desarrollo de equipos de proyectos informáticos . Revista Española de
Documentación Científica.
[171 Mesquita, F. &. (2012) . Alinhando objetivos estratégicos e processo de
desenvolvimento em emp r esas de software. Produ9ao .
[18) Patusco Machado. (2015 ). ITIL aplicado ao Ciclo de Vida de Aplica96es
Distribuídas. Estudo de Caso. Maetría.
[19) Prado A. E. P. & Duarte A. C. O. & Campos F. C. & Pacagne lla A. C. J.
(201 4). Gestao ágil de projetos usando metodologia Scrum: urna análise
em urna empresa da área de tecnología de informa9ao . lberoamerican
Journal of Project Management .
[201 Rahman1 & Sah ibud din2 & Suhaimi l. (2012). A Multi-Process Oual ity <
z
'.
Journal on Computing (JoC) Vol. 2 No. 1, 208-2013. <
o
"'
[211 Rocha L. O. & Santo ro G. G . & Policarpo F. L. (2014). Análise de Riscos "<
pelo Uso de Métodos Ágeis na Gestao de Projetos de Desenvolvimento de "'...<
~
Software. Revista de Gestao e Profetas . ~
>
z
::::>
[221 Solarte , L. P. (2014) . Gerencia de proyectos y estrategia organizaciona l : z
-O
ü
el modelo de madurez en Gestión de Proyectos CP3M © V5 .O. Revista de o<
z
Ciencias Administrativas y Sociales . "'
u.
[231 Vicente S. O. & Ma rtínez A. S. & Berges L. M. , V. (2015). Buenas "'""

prácticas en la gestión de proyectos de 1 + D + i, capacidad de absorc ió n
de conocimiento y éxito . Dyna .
Referencias bibliográficas
[ 11 Ka r en, N . (2009). An e xplo ration of the Maturity Model concept as a

vehicle for higher education institutions to assess their capability to
address student engagement. A work in progress. ergo, 29-36.

Impreso en España
« No está permitida la reproducción total o parcial de este libro, ni su tratamiento
informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea
electrónico, mecánico, por registro u otros métodos, sin permiso previo y por
escrito de los titulares».
lmpresso em Espanha
« Nao está permitida a reproduc;ao total ou parcial deste livro, nem seu tratamento
informático, nem a transmissao de nenhuma forma ou por qualquer meio, seja
eletronico, mecanico, por registro ou outros métodos, sem permissao prévia e por
escrito dos titulares ».
Printed in Spain
« lt is forbidden the total or partial reproduction of this book, including computer
processing and reproduction in any form or by any means, electronic, mechanical,
record ing, or otherwise, without the prior and written consent of its holders ».
Imprimé en Espagne
« La reproduction totale ou partielle de ce manuel , son traitement informatique, sa
transmission sous n'importe quelle forme ou mayen de communication que ce
soit - électronique, mécanique , par enregistrement ou autres méthodes-, sont
interdits sauf autorisation préalable et écrite de ses titulaires ».
ISBN: 978-84-9079-020-5

Dirección Estratégica Tic

Cargado por

Copyright:

Formatos disponibles

Dirección Estratégica Tic

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dirección Estratégica Tic

Cargado por

Copyright:

Formatos disponibles

FUNIBER 9

Capítulo 1 •• Teoría del proyecto tecnológ ico

Capítulo 2 •• Gestión de proyectos

DIRECCIÓN Y GESTIÓ N DE PROYECTOS T IC

2. 5. l. l. El Marco de Referencia de ITIL .. .. .. . .. .. .. .. . .. .. .. .. .. .. . .. .. .. .. .. .. .. .. .. 87

II DIR ECCIÓ N Y GESTIÓN DE PROYECTOS TI C

Capítulo 4 •• Ejemplo de proyecto tecnológico:

4.1. Introducción ........................ ......................................... ... ........... .. ... .............. 193

D IRECCIÓN Y GESTIÓN DE PROYECTOS TIC 111

IV DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC

D IRECCIÓN Y GESTION DE PROYECTOS TIC V

En el ámbito de la Informática, de los Sistema de Información o de los Sistem as de

DIRECCIÓN Y GEST!ON DE PROYECTOS T IC 1

La distinción en los tiempos modernos con relación a estos proyectos tecnológicos es

de proyectos. A la fecha , y de experiencias dive rsas , se ha mostrado que la gestión de B

Los capítulos son:

• Capítulo 1. Teoría del proyecto tecnológico. Ex posición de la teoría de pro yectos a

• Capítulo 2. Gestión de Proyectos. Revisión del campo de la gestión de proy ectos ,

• Capítulo 3. Ingeniería de Software y Gestión de Proyectos. Integración de

2 D IRECCIÓ N Y GESTIÓN DE PROYECTOS TIC

• Capítulo 4 . Ejemplo de proyec to tecnológico : implantació n del proyecto e-Business.

• Capítulo 5. Herramientas y técnicas de gestión de proyectos. Rev isión

Dominar las herramientas y técnicas de gestión de proyectos en proyectos de

Objetivos Espe cíficos

• Distinguir los diversos aspectos de un proyecto tecnológ ico informático y el

• Deli near cómo se organiza la implantació n de un tipo de proyecto tecno lógico en su

• Identificar las herramientas y técnicas de gestión de proyectos idóneas a un

DIRECCIÓN Y GESTIÓN DE PROYECTOS TI C 3

- Conocer y comprender las dimensiones de un proyecto informático

- Reconocer la importancia de una Teoría de Proyectos.

- Comprender la complejidad de un proyecto e-Business desde una perspectiva teórica .

DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC 7

Figura 1.1: Proyecto e-Business.

8 DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC

Para comprender esta definición , es necesario presentar varios conceptos generales,

• Es habitualmente injertada en la misma organización que la requirió , por lo cual la

• En sí mi sma req uiere de un a empatía y un equilibrio entre lo que se pide, desea o

DIRECCIÓN Y GESTION DE PROYECTOS TIC 9

• Limitación de tiempo . Un proyecto debe estar acotado en términos del principio y el

• Tener objetivos específicos;

• Deben completarse dentro de un periodo determinado;

10 DIRECCIÓN Y GESTJON DE PROYECTOS TIC

• Tene r inicios y té rminos bien definidos;

• Deben completa rse dentro de las restricciones de un presupuesto;

• Ser ejecutados po r un equipo; y,

Las acepciones previas pueden considerarse extremas dentro de un amplio abanico de

• Es el conjunto de acciones destinadas a reso lver o vulnerar un problema ya

• Es un conjunto autónomo de inversiones, pol ít icas y medidas instituciona les y

DIRECCIÓN Y GESTIÓN DE PROYECTOS TIC 11

• Es un conjunto específico de actividades en las que se invierten escasos

• Es el conjunto de acciones o actividades que se realiza a partir de una situación

• Es la unidad operativa más pequeña que puede ser ejecutada en forma

• Es una información estructurada con valor agregado que permite la articulación

• Es una empresa planificada con un conjunto de actividades para alcanzar un

• Es un proceso cuyo objetivo es transformar una idea en un producto term inado,

Es un proceso finito , es deci r, que se cuenta con un per íodo de tiempo

Cuenta con un presupuesto preestablecido para alcanzar el objetivo.

• Es un conjunto no vacío de tareas estructuradas, que se desarrollan en un plazo

• Es un proceso único, consistente en un conjunto de actividades controladas,