propuesta para trabajo de grado - …pegasus.javeriana.edu.co/~cis0810is10/memorias.pdf · cada uno...

CIS0810IS10

GUÍA PARA APOYAR LOS PROCESOS DE CONTROL Y SEGUIMIENTO DE LA

GERENCIA DE PROYECTOS DE SISTEMAS DE INFORMACIÓN, BASADA EN EL

ESTÁNDAR COBIT 4.0.

DIANA ANGELICA AVELINO CHALA

DIANA NATHALY BARRERA CAMARGO

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERÍA

CARRERA DE INGENIERÍADE SISTEMAS

BOGOTÁ, D.C.

2008

Pontificia Universidad Javeriana Memoria de Trabajo de Grado - Proyecto de Investigación

Página 1

Preparado por el Grupo Investigación Istar- Versión 1.01 – 12/03/2008

CIS0810IS10

GUÍA PARA APOYAR LOS PROCESOS DE CONTROL Y SEGUIMIENTO DE LA

GERENCIA DE PROYECTOS DE SISTEMAS DE INFORMACIÓN, BASADA EN EL

ESTÁNDAR COBIT 4.0.

Autor(es):

Diana Angélica Avelino Chala

Diana Nathaly Barrera Camargo

Trabajo de Grado presentado para optar el título de Ingeniero de Sistemas

Director

Jacqueline Becerra Silva



CARRERA DE INGENIERÍA DE SISTEMAS

BOGOTÁ, D.C.

Diciembre, 2008

Ingeniería de Sistemas Sistemas de Información - CIS0810IS10

Página 2

NOTA DE ACEPTACIÓN

______________________________________________________

______________________________________________________

______________________________________________________

_____________________________________________

JACQUELINE BECERRA SILVA

Director del proyecto

________________________________________

Jurado

________________________________________

Jurado

DICIEMBRE DE 2008


Página 3




CARRERA DE INGENIERÍA DE SISTEMAS

Rector Magnífico

Joaquín Emilio Sánchez García S.J.

Decano Académico Facultad de Ingeniería

Ingeniero Francisco Javier Rebolledo Muñoz

Decano del Medio Universitario Facultad de Ingeniería

Padre Sergio Bernal Restrepo S.J.

Directora de la Carrera de Ingeniería de Sistemas

Ingeniero Luis Carlos Díaz Chaparro

Director Departamento de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez


Página 4

Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyec-

tos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y

porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos

el anhelo de buscar la verdad y la Justicia”


Página 5


AGRADECIMIENTOS

Agradecemos a Dios y a nuestros padres por darnos la oportunidad de estudiar y apoyarnos a lo

largo de nuestra carrera. Por darnos de ánimo y de ganas de salir adelante.

A nuestros amigos porque fueron el continuo apoyo a lo largo de todo este trabajo y la mayoría de

la carrera. Gracias por estar ahí en todo momento dispuestos a colaborarnos y enseñarnos lo que

cada uno tiene para ofrecer, a apreciar las diferencias y por permitirnos crecer juntos durante todo el

tiempo que pasamos juntos.

A nuestros profesores por todo su esfuerzo y dedicación, porque sin ellos no habríamos aprendido

ni los contenidos de las materias ni todas las lecciones que nos hicieron madurar y ser las personas

que somos hoy.

A la carrera de Ingeniería de Sistemas de la Pontificia Universidad Javeriana por mantenerse actua-

lizados y siempre atentos a nuestras solicitudes.

A las personas que nos ayudaron en las correcciones: Dora Ariza, Henry Cortés Contreras y Jaime

García por su dedicación y valiosos comentarios sobre el documento.

A nuestro directora: Ing. Jacqueline Becerra Silva por ser nuestra guía a lo largo de todo el trabajo y

darnos muy sabios consejos.


Página 6

Contenido

INTRODUCCIÓN ..................................................................................................... 11

I – DESCRIPCIÓN GENERAL ............................................................................... 12

OPORTUNIDAD Ó PROBLEMÁTICA ..................................................................... 12 1.1 DESCRIPCIÓN DEL CONTEXTO ............................................................................. 12 1.2 FORMULACIÓN ........................................................................................................ 15

2. DESCRIPCIÓN DEL PROYECTO ......................................................................... 15 2.1 VISIÓN GLOBAL ........................................................................................................ 15 2.2 JUSTIFICACIÓN ........................................................................................................ 15 2.3 OBJETIVO GENERAL ............................................................................................... 16 2.4 OBJETIVOS ESPECÍFICOS ...................................................................................... 17 2.5. METODOLOGÍA PROPUESTA ................................................................................ 17

II - MARCO TEÓRICO ............................................................................................ 20 3. ESTÁNDARES CONSULTADOS .................................................................................. 22 3.1 ¿QUÉ ES ITIL? ........................................................................................................... 22 3.1.1. ITIL En La Actualidad ............................................................................................ 25 3.2. ¿QUÉ ES COBIT? ..................................................................................................... 26 3.2.1 Principales Características De COBIT ................................................................... 27 3.3. ¿QUÉ ES ISO 27000? ............................................................................................... 29 3.3.1 Evolución de la ISO 27000 ...................................................................................... 29 3.3.2 La ISO 27000 En La Actualidad .............................................................................. 30 3.4. ¿QUÉ ES PMBOK? ................................................................................................... 33 3.4.1. Componentes Del PMBOK ..................................................................................... 33 3.4.2. Grupos De Procesos De PMBOK ........................................................................... 34 3.5. ¿QUÉ ES PRINCE? ................................................................................................... 43 3.5.1 La Metodología De PRINCE2 ................................................................................. 43 3.6. ISO 12207 .................................................................................................................. 46 3.6.1. Procesos Principales De La ISO 12207 ................................................................. 46 3.7. ¿QUÉ ES CMMI / CMM? .......................................................................................... 50 3.7.1. Características de CMMI / CMM .......................................................................... 51 3.7.2. Niveles de Madurez de CMMI ................................................................................ 51 3.7.3. CMM En Las Organizaciones................................................................................. 53 3.7.4. Qué es el SE-CMM? ............................................................................................... 53 3.7.5. Otros Modelos de CMM ......................................................................................... 54 3.8. ¿QUE ES EL BALANCE SCORECARD? .................................................................. 55


Página 7


3.8.1. Objetivos del BSC ................................................................................................... 55 3.8.2. Características del BSC .......................................................................................... 56 3.8.3. Las cuatro perspectivas del BSC ............................................................................ 57

III - PROCESO .......................................................................................................... 60

4. LEVANTAMIENTO DE INFORMACIÓN ............................................................ 60

5. ANÁLISIS DE LA INFORMACIÓN RECOPILADA ............................................ 61

6. DISEÑO DE LA GUÍA ............................................................................................ 63

8. REFLEXIÓN METODOLÓGICA .......................................................................... 74

9. RESULTADOS ....................................................................................................... 75

10. RECOMENDACIONES ........................................................................................ 76

11. CONCLUSIONES ................................................................................................. 77

12. TRABAJOS FUTUROS ........................................................................................ 79

13. REFERENCIAS .................................................................................................... 80

14. BIBLIOGRAFÍA ................................................................................................... 82


Página 8

LISTA DE ILUSTRACIONES

Ilustración 1. ESTRUCTURA DE ITIL ............................................................................................ 24

Ilustración 2. ISO 27000 ................................................................................................................... 33

Ilustración 3. Grupo de Procesos de Iniciación ................................................................................. 34

Ilustración 4. Grupo de Procesos de Planificación ............................................................................ 37

Ilustración 5. Grupo de Procesos de Ejecución ................................................................................. 39

Ilustración 6. Grupo de Procesos de Seguimiento y Control ............................................................ 41

Ilustración 7. Grupo de Procesos de Cierre ....................................................................................... 42

Ilustración 8. Grupo de Procesos de ISO 12207 ............................................................................... 47


Página 9


ABSTRACT

This research work presents a guide based on the relationship of the concepts of auditing and

project management to make more efficient monitoring and control activities of the project under-

taken by the project manager of Information Systems, which seeks to support its management and

allow the project scope the goal This was done for a lifting of information on best practices current-

ly supporting the processes of management as well as the experience of some engineers who have

worked under the role of managers, and then conduct an analysis of the problems experienced by

projects related to information systems seeking to identify the causes of failure and success.

RESUMEN

Este trabajo investigativo presenta una guía basada en la relación de los conceptos de auditoría y

gerencia de proyectos para hacer más eficientes las actividades de seguimiento y control del pro-

yecto realizadas por el gerente de proyectos de Sistemas de Información, mediante la cual se busca

apoyar su gestión y permitir que el proyecto alcance la meta propuesta. Para esto se realizó un

levantamiento de información respecto de las mejores prácticas que actualmente apoyan los proce-

sos de gerencia así como de la experiencia de algunas ingenieros que han trabajado bajo el rol de

gerentes, para luego efectuar un análisis de la problemática que sufren los proyectos relacionados

con sistemas de información buscando identificar las causas de fracaso y de éxito.


Página 10

RESUMEN EJECUTIVO

Actualmente, los gerentes de proyectos realizan sus funciones de gestión para llevar a cabo un pro-

yecto de manera exitosa basándose en metodologías reconocidas que dan algunas pautas de lo que

se debería hacer al momento de asumir la gerencia. Dichas metodologías hacen explícito que se

debe tener en cuenta; no obstante ninguna de ellas ayuda a desarrollar el cómo. Es función y res-

ponsabilidad del gerente del proyecto crearlo o adaptarlo de acuerdo a lo que conoce y a su expe-

riencia.

Ahora bien, además de seguir una metodología es necesario que el gerente lleve a cabo el segui-

miento y control de un proyecto para garantizar la meta propuesta.

El objetivo de este trabajo de grado es desarrollar una guía que apoye la gestión de seguimiento y

control que debe realizar el gerente y que también permita “medir” su desempeño al frente del pro-

yecto. Para esto se revisaron varios estándares del mercado como son COBIT, PMBOK, ISO 17799,

entre otros, con los cuáles se pretendió obtener aportes teóricos para ampliar el conocimiento de las

autoras y así lograr construir la estructura de la guía apoyándose en las mejores prácticas propuestas

por estos. Además, la guía se diseño haciendo uso de listas de chequeo las cuáles son una herra-

mienta utilizada por el área de auditoría, aplicables como instrumentos a otras áreas y que serán

usadas para identificar, a través del desarrollo del proyecto, los aspectos que se pueden mejorar y

cuáles se pueden tener en cuenta para la gestión de un próximo proyecto.

Finalmente, se invitó a tres (3) profesionales para que validaran la guía en alguno de los proyectos

en que estuvieran participando, con el objetivo de retroalimentar el objeto construido y hacer los

ajustes recomendados por ellos.


Página 11


INTRODUCCIÓN

El trabajo de grado propuesto pretende presentar una guía como herramienta de apoyo para que el

gerente de proyectos de Sistemas de Información haga el proceso de seguimiento y control de los

proyectos a su cargo de una manera más eficiente y le permita adicionalmente medir su gestión en

cada uno de ellos, de tal forma que por cada proyecto se documenten las lecciones aprendidas que

puedan ser aplicadas a otros.

Para alcanzar esta meta, en el primer capítulo de este documento se realiza tanto una breve descrip-

ción de la problemática que se pretende abordar como los objetivos y la justificación de la propues-

ta que se llevó a cabo. También se explica cuál fue la metodología que se utilizó y que fue desarro-

llada en los capítulos siguientes.

En el segundo capítulo, el cuál corresponde al Marco Teórico, se encuentra la consulta de informa-

ción de los diferentes estándares entre ellos: COBIT, ITIL, ISO 17799, PMBOK, PRINCE2 entre

otros, que aportaron lineamientos importantes para el desarrollo de la propuesta. En el siguiente

capítulo, se da inicio al desarrollo de la metodología usada para la elaboración del Trabajo de grado

y la generación de la guía. Además se encuentra la reflexión metodológica acerca de la metodología

utilizada y como puede mejorarse en futuros trabajos.

A continuación, el cuarto capítulo del documento, describe los resultados obtenidos luego de reali-

zar la validación de la guía y las recomendaciones obtenidas por parte de las personas que estuvie-

ron involucradas en dicha actividad.

Finalmente, el quinto capítulo presenta las conclusiones y una propuesta de futuros proyectos que

pueden plantearse partiendo de los resultados del presente trabajo de grado.


Página 12

I – DESCRIPCIÓN GENERAL

OPORTUNIDAD Ó PROBLEMÁTICA

1.1 DESCRIPCIÓN DEL CONTEXTO

Cuando en una organización se pretende realizar un proyecto relacionado con el área de sistemas o

de tecnología, se utilizan estándares internacionales que desarrollan el tema bajo el enfoque de

Gerencia de Proyectos. Algunos de los más relevantes son:

PMBOK, el cuál es un estándar en la gestión de proyectos desarrollado por el Project Manage-

ment Institute (PMI) que tiene como propósito describir el conocimiento y las buenas prácticas

“aplicables a la mayoría de los proyectos, la mayor parte del tiempo y que existe un amplio

consenso sobre su valor y utilidad.”1

. Este estándar describe Procesos de Gestión de Proyectos

(Inicio, planificación, ejecución, control y monitoreo, y cierre), los cuales pertenecen a las nueve

Áreas de Conocimiento de Gestión de Procesos: Gestión de la Integración, Gestión del Alcance,

Gestión del Tiempo, Gestión del Costo, Gestión de la Calidad, Gestión de recursos Humanos,

Gestión de las Comunicaciones, Gestión del Riesgo y Gestión del Abastecimiento, definidas por

el PMBOK.

PRINCE2 (Proyectos IN Entornos Controlados) “Es un método estructurado para la administra-

ción efectiva de proyectos. Es un estándar de facto utilizado extensamente en el gobierno del Re-

ino Unido y es ampliamente reconocido y utilizado en el sector privado, tanto en el Reino Unido

como internacionalmente”2

. Algunas de las principales características de PRINCE2 son: enfoque

en la justificación de negocios, definición de una estructura de organización para el equipo de

gestión de proyecto, y énfasis en dividir el proyecto en fases manejables y controlables.

1

Project Management Institute. (2004). Guía de los Fundamentos de la Dirección de Proyectos - Tercera Edición. New-

town Square, PA. 2

ILX Group plc. (2008). PRINCE2 Foundation & PRINCE2 Practitioner Project Management Training. Recuperado el

20 de Marzo de 2008, de http://www.prince2.com/what-is-prince2.asp.


Página 13


Por otra parte, cuando el proyecto a desarrollar posee un gran componente de software se asocian

dichas implantaciones con el uso de procesos tales como:

CMMI, “Es un proceso enfocado en la mejora que proporciona a las organizaciones los elemen-

tos esenciales para la eficacia de los procesos. Se puede utilizar para guiar el proceso de mejora a

través de un proyecto, una división, o de toda una organización”3

. Este estándar ayuda a mejorar

ó a evaluar 22 áreas de proceso que integran desarrollo de software e ingeniería de sistemas

(CMMI-SE/SW) y 25 en la que cubre también integración de producto (CMMI-SE/SW/IPPD).

Estos estándares pueden ser utilizados por la persona que se encuentra a cargo de la dirección de un

proyecto, la cual cumple el rol de gerente de proyecto, quien debe llevar a cabo la planeación de las

actividades y la asignación de las mismas a cada participante del equipo para lograr el cumplimien-

to de todos los objetivos del proyecto, tanto en calidad, tiempo y costos.

Para entender las funciones que cumple este perfil, es necesario entender el alcance del concepto de

proyecto y gerencia de proyectos. El primero según la guía del PMBOK del estándar PMI (Project

Management Institute), indica que “un proyecto es una iniciativa temporal para crear un producto o

servicio específico”4

. Estos proyectos según el PMBOK tienen tres características:

1. Tienen un inicio y un final. El fin es alcanzado cuando los objetivos del proyecto son logrados o

cuando se sabe que estos no serán o no pueden ser alcanzados, o cuándo la necesidad del proyecto

no existe más y el proyecto es terminado. 2. El resultado del proyecto es un producto único o un

servicio. 3. Un proyecto tiene una elaboración progresiva, es decir se procede siguiendo pasos.

De acuerdo a lo anterior, se construye la definición de la gerencia de proyectos como: “la aplicación

de conocimiento, habilidades, herramientas y técnicas a las actividades del proyecto para alcanzar

3

Software Engineering Institute. Software Engineering Institute-Carnegie Mellon. 2008.

http://www.sei.cmu.edu/cmmi/general/index.html (último acceso: 18 de Marzo de 2008). 4

V Encuesta de Gerencia de Proyectos. Vigil, Alberto Cueto. 2007. Bogotá : s.n., 2007.


Página 14

los objetivos propuestos. La gerencia de proyectos se logra a través del uso de procesos como: ini-

ciación, planeación, ejecución, control y cierre”5

.

Por otra parte, de acuerdo a autores como Steve McConnell, el gerente de proyectos se encuentra

con diversos problemas. En su libro “Desarrollo y gestión de Proyectos Informáticos”, la causa de

estos problemas los asocia con cuatro tipos de errores, a saber:

Personas: Los errores más comunes que se presentan en este aspecto se relacionan con la

parte emocional y psicológica de las personas así como sus relaciones interpersonales, la

poca participación por parte de los involucrados en el proyecto y la contratación de perso-

nal que no cumple con el perfil requerido. Otro error común es cuando se intenta solucio-

nar un retraso del proyecto incluyendo más personas creyendo que así se aumenta la pro-

ductividad, pero sucede lo contrario, debido a que los nuevos integrantes no tienen el co-

nocimiento inicial del proyecto.

Proceso: Los principales errores se relacionan con el proceso de planeación ya sea porque

se hace excesivamente optimista, porque es insuficiente, ó porque se deja de hacer cuando

se encuentra bajo presión. En este aspecto también se presenta la falta de actualización de

la planificación realizada inicialmente, esto se hace necesario para garantizar que se alcan-

ce a tiempo la fecha de entrega del proyecto. Además de lo mencionado anteriormente,

otro error común es no realizar una adecuada gestión de riesgos así como de calidad.

Producto: En cuanto al desarrollo del producto, se pueden presentar errores en cuanto a los

requerimientos debido a cambios excesivos ó porque no tienen un alcance bien definido.

Como consecuencia de esto, se generan cambios más grandes que afectan el plan del pro-

yecto definido inicialmente.

Tecnología: En este aspecto los errores están relacionados con su uso, ya que no es sufi-

ciente implementar los últimos avances de tecnología en un proyecto si ésta no se encuen-

5

Project Management Institute. (2004). Guía de los Fundamentos de la Dirección de Proyectos - Tercera Edición. New-

town Square, PA.


Página 15


tra alineada con la estrategia del negocio y no satisface las necesidades del usuario; esto

puede convertirse en un gasto innecesario y poco útil.

Aunque es común encontrar estos problemas durante la gerencia de proyectos, es posible reducir la

probabilidad de que se presenten por medio de una adecuada gestión que involucre un proceso de

seguimiento y control eficiente del proyecto, por medio del cual se logren identificar a tiempo para

tenerlos en cuenta y realizar acciones correctivas si es necesario.

1.2 FORMULACIÓN

Teniendo en cuenta que los gerentes de proyectos de sistemas de información están interesados en

adquirir el conocimiento necesario para mejorar la gestión en su trabajo, y así procurar que sus pro-

yectos cumplan con las metas propuestas principalmente en cuanto a calidad, duración y costos, es

posible pensar en que además de seguir estándares tradicionales de gerencia de proyectos, esta dis-

ciplina se pueda complementar con herramientas de otras áreas para poder lograr la mejor adminis-

tración posible. Es por esto que se plantea la siguiente pregunta:

¿Cómo se puede apoyar la gestión de los gerentes de proyectos, para realizar un control y segui-

miento al desarrollo de proyectos de sistemas de información y lograr una mayor probabilidad de

éxito en la implantación del mismo?

2. DESCRIPCIÓN DEL PROYECTO

2.1 VISIÓN GLOBAL

En este trabajo investigativo se busca elaborar una guía que apoye el proceso de seguimiento y con-

trol que debe realizar la gerencia de proyectos de Sistemas de Información, soportándose en buenas

prácticas usadas por los gerentes en la ejecución exitosa de cada una de las actividades que con-

forman las etapas del proyecto.

2.2 JUSTIFICACIÓN

Según la encuesta realizada por ACIS (Asociación Colombiana de Ingenieros de Sistemas), en el

marco de la V Jornada Nacional de Gerencia de Proyectos de TI, algunas de las características que


Página 16

deben tener los gerentes son liderazgo, trabajo en equipo, planeación, comunicación oral, gestión

del tiempo, experiencia, habilidad para manejar el cambio y gestión de recursos.

Aunque es deseable que los gerentes posean estas habilidades, aún se siguen presentando fracasos

en el desarrollo de proyectos, por la deficiencia y/o carencia de algunas de ellas, tal y como es se-

ñalado en los resultados de la encuesta que indica: con un 19.66% la mala planeación, proyectos

idealistas un 17.95%, mala comunicación un 11.11% e inadecuado control de cambios (9.40%)6

,

entre otros.

A partir de la revisión y análisis que se llevó a cabo de esta encuesta y la realizada para el año 2008,

en las cuales se hace un acercamiento para determinar cuáles son los factores críticos de fracaso y

de éxito que se presentan al gerenciar proyectos de Sistemas de Información, se consideró impor-

tante proponer una herramienta de apoyo para hacer seguimiento y control a las actividades que se

realizan dentro del mismo con el objetivo de evitar que los factores identificados en dichas encues-

tas afecten su desarrollo ya que a pesar de que existan metodologías que guían las funciones de un

gerente, estas no hacen explícito cómo se deberían ejecutar las buenas prácticas recomendadas.

Esta herramienta permite identificar posibles falencias y fortalezas durante las fases de inicio, eje-

cución y cierre de un proyecto, de tal manera que se puedan corregir a tiempo las debilidades en-

contradas y así evitar que afecte el desarrollo normal del mismo. A lo largo del desarrollo del pro-

yecto se propone ir documentando las lecciones aprendidas que deberían ser usadas en otros de tal

manera que pueden aportar a la gestión de estos.

2.3 OBJETIVO GENERAL

Proporcionar una herramienta basada en los lineamientos del estándar COBIT 4.0 para que los ge-

rentes de proyectos de sistemas de información apoyen sus procesos de control y seguimiento du-

rante el ciclo de vida del proyecto.

6



Página 17


2.4 OBJETIVOS ESPECÍFICOS

Analizar tanto el nivel de conocimiento que tienen los gerentes de proyectos de sistemas de

información acerca de las herramientas de control y seguimiento y de los estándares que

puedan apoyar estos procesos, como la forma de desarrollo de estas actividades.

Identificar y analizar los objetivos de control de cada uno de los dominios definidos por

COBIT 4.0 que aporten al seguimiento y control de la gerencia de proyectos.

Diseñar la guía que apoye al gerente de proyectos de sistemas de información en los proce-

sos de seguimiento y control basados en el análisis previo.

Validar la guía propuesta en un escenario de prueba específico, para poder realizar la eva-

luación respectiva.

2.5. METODOLOGÍA PROPUESTA

Como se trata de un proyecto de investigación de carácter explorativo, la metodología usada será el

método científico, y las fases que se seguirán son descritas en el Módulo 2 llamado “La Investiga-

ción” perteneciente a la serie “Aprender a Investigar”7

, desarrollada por el ICFES, Instituto Colom-

biano para el Fomento de la Educación Superior.

La materialización de esta metodología en el proyecto de investigación será detallada a continua-

ción:

Levantamiento de Información: En primer lugar, se efectuará un estudio de las principales meto-

dologías de gerencia de proyectos tales como PMBOK, PRINCE2, CMMI y las pertenecientes a

7

Tamayo, Mario Tamayo y. «ICFES.» ICFES. 1999. http://200.26.128.174:8080/portalicfes/home_2/rec/arc_71.pdf

(último acceso: 19 de Marzo de 2008).


Página 18

ISO (International Organization for Standarization). Además se estudiarán las buenas prácticas que

supervisen y controlen los procesos relacionados con Tecnología de la Información tales como

ITIL, COBIT 4.0, entre otros.

A continuación, se realizará una recopilación de información para identificar qué nivel de conoci-

miento tienen los gerentes de proyectos de sistemas de información, respecto a los estándares inves-

tigados, y conocer cómo realizan el seguimiento y control de sus proyectos teniendo en cuenta los

criterios que aplican, herramientas que usen, entre otros.

Para esta actividad, se debe llevar a cabo la definición de la muestra objetivo de los gerentes de

proyectos a los cuáles se les aplicará la entrevista. El perfil de estos gerentes corresponde a Ingenie-

ros de Sistemas o de ciencias afines que tengan como mínimo dos años de experiencia en el área de

Gerencia de proyectos de Sistemas de Información. Además es deseable pero no obligatorio, que

posean una especialización en Gerencia de Proyectos o Certificación en Gerencia.

Esta fase corresponde a la percepción del problema a tratar, como parte de las fases definidas en el

método científico.

Análisis de la información recopilada: En esta fase se desarrollará:

El estudio y análisis comparativo de la información recopilada de las metodologías para la

gerencia de proyectos, así como de las buenas prácticas para el control y seguimiento de los

procesos referentes al área de tecnología de la información.

Análisis de los resultados de las entrevistas efectuadas.

Revisión de plantillas de guías existentes para el desarrollo de la guía a proponer dentro del

trabajo.

Aquí se llevará a cabo la identificación y definición del problema anteriormente hallado, con base a

la información obtenida.

Diseño de la Guía: Se propondrá la guía que apoye a los Gerentes de Proyectos de Sistemas de

Información al seguimiento y control de los mismos de acuerdo a los resultados arrojados en la

etapa anterior. En esta fase se propondrá una solución al problema identificado previamente.


Página 19


Aplicación y Validación: Finalmente, para permitirse obtener una validez de la propuesta, se lle-

vará a cabo la valoración de la guía con las opiniones de algunos de los gerentes de proyectos de

Sistemas de Información a los cuáles se les realizó la entrevista. En otras palabras se llevará a cabo

la validación de la solución propuesta.


Página 20

II - MARCO TEÓRICO

En Colombia, dentro del marco de la III Jornada de Gerencia de proyectos de software, celebrada en

Bogotá en Marzo de 2005, se realizó una presentación titulada: “Porque fracasan los Gerentes de

Proyectos en Colombia”8

, en la cual se exponen las siguientes causas de fracaso, entre otras:

1. La mayoría de los gerentes de proyectos de software desconocen su rol, tanto desde el pun-

to de vista de la ingeniería como de la gerencia de proyectos.

2. No se fundamentan en hechos y datos. Por lo tanto, operan sin información. Creen que los

proyectos van bien hasta que explotan. El monitoreo y control es fundamental en cualquier

proyecto.

3. En muchos casos no se documentan las lecciones aprendidas.

Para lograr evitar lo anterior, los gerentes de proyectos han venido mostrando interés en mejorar

sus conocimientos. A través de la encuesta de ACIS en la V jornada de gerencia mencionada ante-

riormente, se permitió evidenciar cómo los profesionales que hacen las veces de gerentes de proyec-

tos han venido adquiriendo conocimientos que los acreditan en ese campo profesional, ya sea a

través de una Certificación PMP (Project Management Profesional), emitido por el PMI (Project

Management Institute) ó mediante la obtención de un título de especialista en el área de gerencia.

Las cifras que apoyan lo anterior corresponden, para el 2007, a un 58.25%9

de gerentes que han

adquirido algún título de especialización o certificación.

De esta manera se puede concluir, que estos profesionales se están preparando para obtener herra-

mientas y conocimiento acerca de estándares para lograr cada vez más aumentar el éxito en los pro-

8

Porque fracasan los Gerentes de Proyectos En Colombia. PSL-Productora De Software S.A. 2005. Bogotá : s.n.,

2005. 9



Página 21


yectos por ellos dirigidos, buscando no improvisar en cada una de las fases que pertenecen a un

proyecto.

Cabe señalar que en la función de gerencia de proyectos, cada gerente diseña sus propias herra-

mientas ó se apoya en algunas ya existentes, y en otros casos se trabaja empíricamente. Para el se-

gundo aspecto, se cuenta en el mercado con soluciones para la administración y control de activida-

des como son Microsoft Project ó soluciones de código abierto como GanttProject, openworkbench,

OpenProj, etcétera, las cuáles permiten administrar tanto recursos, tiempo y el desarrollo de las

tareas. Otras herramientas menos sofisticadas, como las hojas de cálculo, permiten elaborar los flu-

jos de caja para controlar los ingresos y costos de los proyectos. Sin embargo, algunos profesiona-

les que ejercen el rol de gerente de proyectos no poseen el conocimiento de la operación de las ante-

riores y en muchos casos su trabajo se basa en la experiencia.

Mientras tanto, en áreas como la de auditoría, sus profesionales han venido trabajando con el con-

cepto de guías, las cuáles se constituyen en herramientas que ayudan, de acuerdo a un objetivo, a

realizar el seguimiento y control de las actividades o tareas a desarrollar. Estas son creadas por cada

individuo y buscan apoyar la gestión que se desarrolla para un trabajo y sirven como lineamientos a

seguir para cada tema. Dicha herramienta podría ser muy útil para apoyar al gerente de proyectos en

las actividades de seguimiento y control en un esquema más formal y efectivo. No obstante, no

todos cuentan con las habilidades para diseñar guías de trabajo, ya sea porque no conocen el con-

cepto, el contenido de las mismas o porque no saben estructurar la guía.

Asociaciones de profesionales en Auditoría de Sistemas de Información, como es ISACA, (Infor-

mation Systems Audit and Control Association) se han preocupado en elaborar estándares y guías

para ofrecer una metodología definida que apoye el proceso de planeación, ejecución y dictamen de

la auditoría. Dentro de los estándares que ésta asociación ha desarrollado se encuentra COBIT, el

cual es una herramienta de gobierno de TI que ha influido significativamente en el desarrollo del

trabajo de los profesionales de tecnología, proporcionando buenas prácticas a través de un marco de

procesos y de dominios, y presentando actividades en una estructura lógica y manejable. “Este

modelo consolida y armoniza estándares de fuentes globales prominentes en un recurso crítico para


Página 22

la gerencia, los profesionales de control y los auditores”10

. COBIT se aplica tanto a los sistemas de

información como también al hardware de la organización (computadores personales y redes).

Además, promueve la idea de que se deben administrar los recursos de TI mediante un conjunto de

procesos asociados para proveer la información apropiada y confiable que necesita la empresa. Hoy

por hoy el estándar no sólo es usado por auditores sino también por el personal de TI.

A la luz de lo anterior, y teniendo en cuenta que los profesionales de Tecnología de Información son

los responsables del gerenciamiento de los proyectos de Sistemas de Información, se considera

importante que los mismos reconozcan que es necesario tener una buena práctica con la cual puedan

apoyarse para realizar sus procesos de seguimiento y control, y lograr desarrollar las herramientas

que soporten estas labores.

3. ESTÁNDARES CONSULTADOS

A continuación se da un breve resumen de los estándares y buenas prácticas relevantes para el de-

sarrollo del presente proyecto. Entre éstos esta ITIL, COBIT, ISO 27000, PMBOK, PRINCE2,

CMM/CMMI y Balance Score Card.

3.1 ¿QUÉ ES ITIL?

ITIL es un estándar ampliamente aceptado desarrollado para “la gestión de los servicios de TI en el

mundo. Proporciona un conjunto coherente de las normas de buenas prácticas extraídas de los sec-

tores públicos y privados en todo el mundo, y ha sido objeto recientemente de un importante pro-

yecto de renovación.”11

El estándar ITIL “se centra en ofrecer servicios de alta calidad, partiendo de un enfoque estratégico

basado en el triángulo procesos-personas-tecnología. A partir de este modelo se ofrece un método

10

Channel Planet Inc. 2005. Channel Planet. [En línea] 07 de Febrero de 2005. [Citado el: 22 de Febrero de 2008.]

http://www.channelplanet.com/. 11

OGC Best Management Practice. (s.f.). OGC Best Management Practice - ITIL. Recuperado el 28 de 04 de 2008, de

http://www.best-management-practice.com/Knowledge-Centre/Best-Practice-Guidance/ITIL/?trackid=002205


Página 23


probado para gestionar procesos, roles y actividades, así como sus interrelaciones”12

. Este estándar

es posible utilizarlo en organizaciones que ya tengan sus propios métodos y actividades de Gestión

de Servicios, independientemente de su tamaño. “El gran problema de ITIL es que no cubre ade-

cuadamente las fases de desarrollo de software ni la gestión de proyectos asociada a esa fase de

construcción de activos software”13

.

La estructura de ITIL, según el libro Best practice for ICT infrastructure management14

es:

El área de Administración De Servicios que está compuesta por:

Service Delivery que cubre los procesos requeridos para la planeación y entrega de servi-

cios de calidad de ICT (Information and Communications Technology) y para esto contem-

pla el manejo de niveles de servicio, manejo financiero para servicios de IT, administración

de capacidades, administración de la continuidad de servicio de IT y administración de la

disponibilidad.

Service Support, el cuál describe las funciones de Service desk y sus responsabilidades así

como los procesos requeridos para el soporte continuo y el mantenimiento de servicios de

ICT. En este se tiene en cuenta manejo de incidentes, manejo de problemas, manejo de con-

figuración, manejo de cambios y manejo de liberación.

12

Sánchez, F. (6 de Marzo de 2008). MKM Publicaciones. Recuperado el 26 de Mayo de 2008, de http://www.mkm-

pi.com/mkmpi.php?article1817 13

Ibid. 14

Gran Bretaña. Oficina del Comercio del Gobierno. (2005). Best practice for ICT infrastructure management. London .


Página 24

Ilustración 1. ESTRUCTURA DE ITIL

Fuente: Presentación Alfredo Zayas – ISACA México City Chapter

Además de los dos libros que conforman la administración de servicios, se encuentra el libro “Pla-

neando la implementación de administración de servicios” que examina los problemas y tareas

involucradas en la planeación, implementación y la mejora de los procesos de administración de

servicios en una organización.

Por otra parte, el libro de la perspectiva del negocio apunta a familiarizar la administración del ne-

gocio con los componentes subyacentes de ICTIM (ICT Infrastructure Management), la administra-

ción de servicios y la administración de aplicaciones que son necesarios para soportar sus procesos

de negocio. También permite a los administradores del negocio ganar un entendimiento de los bene-

ficios de las mejores prácticas en administración de servicios de IT con el fin de que ellos puedan

estar mejor informados y más capaces para manejar relaciones con proveedores de servicios para

mutuos beneficios.

La Administración de aplicaciones aborda el complejo tema de la gestión de las aplicaciones para

las iníciales necesidades del negocio, a través de el ciclo de vida de la aplicación, hasta e incluyen-

do su retiro. Este libro enfatiza en asegurar que los proyectos de TI y las estrategias están estrecha-

mente alineados con los de la empresa a lo largo del ciclo de vida de las aplicaciones, a fin de ga-

rantizar que la empresa obtiene mejor valor de su inversión.


Página 25


Por último, el libro la administración de seguridad detalla los procesos de planificación y gestión

de un determinado nivel de seguridad en la información y en los servicios ICT, incluyendo todos los

aspectos asociados con la reacción de incidentes de seguridad.

3.1.1. ITIL En La Actualidad

La versión más reciente es ITILv3, la cual se caracteriza porque establece un vínculo entre las bue-

nas prácticas de ITIL y los beneficios empresariales, más claro y más fuerte. El objetivo es asegu-

rar que ITIL continúe proporcionando una guía actualizada y útil de buenas prácticas a medida que

la tecnología sigue evolucionando15

. El principal cambio que incorpora esta nueva versión, es que

se ha pasado de una estructura basada en procesos, a una estructura basada en el ciclo de vida de los

servicios, con lo cual se puede llegar a una integración de la estrategia del negocio y la estrategia de

los servicios de TI, obteniendo así una mejora continua.

Entre los beneficios que ofrece este estándar se encuentran, entre otros:

[1] Reducción de costos

[2] La mejora de servicios de TI a través del uso de procesos de mejores prácticas.

[3] La mejora de la satisfacción del cliente a través de un enfoque más profesional de la

prestación de servicios.

[4] Mejora de la utilización de los conocimientos y la experiencia.

La versión tres de ITIL está conformada por cinco volúmenes: Estrategia de Servicio, Diseño del

Servicio, Transición del Servicio, Operaciones del Servicio y Mejora Continua del Servicio que

buscan facilitar su aplicación.

1. Estrategia de Servicio (Service Strategy)

15

IT Governance Ltd. (s.f.). IT Governance. Recuperado el 28 de 04 de 2008, de

http://www.itgovernance.co.uk/itilv3.aspx


Página 26

Este libro busca conseguir el alineamiento entre el negocio y TI. Es decir pretende entender

y trasladar las necesidades del negocio a las estrategias de TI y proporciona las herramientas

para una planeación de la gestión de servicio de TI.

2. Diseño del Servicio (Service Design)

Este volumen suministra una guía en la producción y mantenimiento del diseño de arquitec-

turas y políticas de TI sobre el desarrollo de servicios incluyendo insourcing y outsourcing.

3. Transición del Servicio (Service Transition)

Después de definida la estrategia de servicio y diseñado el servicio este se debe poner en

producción, así que este libro se centra en el rol de gestión de cambios y en las prácticas de

lanzamientos.

4. Operaciones del Servicio (Service Operation)

Explica cómo gestionar los servicios en un entorno de producción y se centra en los proce-

sos de entrega y control que permiten tener servicios controlados

5. Mejora continua del Servicio (Continual Services Improvement)

Se enfoca en las entradas y salidas necesarias para el adecuado ciclo de mejora continua so-

bre los servicios existentes.

3.2. ¿QUÉ ES COBIT?

COBIT, publicado en 1996, es una herramienta de gobierno de TI que ha cambiado la forma en que

trabajan los profesionales de TI. Vinculando tecnología informática y prácticas de control, COBIT

consolida y armoniza estándares de fuentes globales prominentes en un recurso crítico para la ge-

rencia, los profesionales de control y los auditores.


Página 27


COBIT se aplica a los sistemas de información de toda la empresa, incluyendo las computadoras

personales, mini computadoras y ambientes distribuidos. Está basado en la filosofía de que los re-

cursos de TI necesitan ser administrados por un conjunto de procesos naturalmente agrupados para

proveer la información pertinente y confiable que requiere una organización para lograr sus objeti-

vos.

La principal misión de COBIT es investigar, desarrollar, publicar y promover un conjunto interna-

cional y actualizado de objetivos de control para tecnología de información que sea de uso cotidiano

para gerentes y auditores.

Los usuarios principales de COBIT son los siguientes:

[1] La Gerencia: para apoyar sus decisiones de inversión en TI y control sobre el rendimiento de

las mismas, analizar el costo beneficio del control.

[2] Los Auditores: para soportar sus opiniones sobre los controles de los proyectos de TI, su im-

pacto en la organización y determinar el control mínimo requerido.

[3] Los Responsables de TI: para identificar los controles que requieren en sus áreas.

[4] Los Usuarios Finales: quienes obtienen una garantía sobre la seguridad y el control de los pro-

ductos que adquieren interna y externamente.

También puede ser utilizado dentro de las empresas por el responsable de un proceso de negocio en

su responsabilidad de controlar los aspectos de información del proceso, y por todos aquellos con

responsabilidades en el campo de la TI en las empresas.

3.2.1 Principales Características De COBIT

A continuación se describen las principales características de COBIT:

Orientado al negocio.

Alineado con estándares y regulaciones "de facto".

Basado en una revisión crítica y analítica de las tareas y actividades en TI.


Página 28

Alineado con estándares de control y auditoría (COSO, IFAC, IIA, ISACA, AICPA).

El enfoque del control en TI se lleva a cabo visualizando la información necesaria para dar soporte

a los procesos de negocio y considerando a la información como el resultado de la aplicación com-

binada de recursos relacionados con las TI que deben ser administrados por procesos de TI.

Según COBIT 4.0, para satisfacer los objetivos del negocio, la información necesita adaptar-

se a ciertos criterios de control, los cuales son referidos como requerimientos de información

del negocio. Es por esto que con base en los requerimientos de calidad, fiduciarios y de se-

guridad, COBIT definió los siguientes siete criterios de información:

Efectividad: La información debe ser relevante y pertinente para los procesos del negocio y

debe ser proporcionada en forma oportuna, correcta, consistente y utilizable.

Eficiencia: Se debe proveer información mediante el empleo óptimo de los recursos (la

forma más productiva y económica).

Confiabilidad: proveer la información apropiada para que la administración tome las deci-

siones adecuadas para manejar la empresa y cumplir con sus responsabilidades.

Cumplimiento: de las leyes, regulaciones y compromisos contractuales con los cuales está

comprometida la empresa.

Confidencialidad: Protección de la información sensible contra divulgación no autorizada.

Integridad: Refiere a lo exacto y completo de la información así como a su validez de

acuerdo con las expectativas de la empresa.

Disponibilidad: accesibilidad a la información cuando sea requerida por los procesos del

negocio y la salvaguarda de los recursos y capacidades asociadas a la misma.

Por otro lado, en COBIT se establecen los siguientes recursos en TI necesarios para alcanzar

los objetivos de negocio:


Página 29


Datos: Todos los objetos de información. Considera información interna y externa, estruc-

turada o no, gráficas, sonidos, etc.

Aplicaciones: entendido como los sistemas de información, que integran procedimientos

manuales y sistematizados.

Tecnología: incluye hardware y software básico, sistemas operativos, sistemas de admi-

nistración de bases de datos, de redes, telecomunicaciones, multimedia, etc.

Instalaciones: Incluye los recursos necesarios para alojar y dar soporte a los sistemas de

información.

Recurso Humano: Por la habilidad, conciencia y productividad del personal para planear,

adquirir, prestar servicios, dar soporte y monitorear los sistemas de Información.

3.3. ¿QUÉ ES ISO 27000?

ISO/IEC 27000 es un conjunto de estándares desarrollados -o en fase de desarrollo- por ISO (Inter-

national Organization for Standardization) e IEC (International Electrotechnical Commission), que

proporcionan un marco de gestión de la seguridad de la información utilizable por cualquier tipo de

organización, pública o privada, grande o pequeña.

3.3.1 Evolución de la ISO 27000

En un comienzo la primera ISO que salió respecto a la seguridad de la información fue la ISO

17799, el cual era un código de práctica, su contenido estaba más estrechamente alineado con las

cuestiones de seguridad cotidiana que la mayoría de las demás publicaciones estándar. “La norma

ISO 17799 se inició a la vida como un documento publicado por el Gobierno del Reino Unido de la

DTI. Esto pronto se convirtió en BS7799, y BSI estándar, y desde allí, fue finalmente publicado


Página 30

como ISO 17799 en 2000. En el 2005, se actualizó y publicó de nuevo, para reflejar los cambios en

la tecnología y los enfoques a las cuestiones de gobernanza”16

.

Finalmente, en el 2007 fue renombrado con la norma ISO 27002, para ocupar su lugar en la serie

ISO 27000 de seguridad de la información relacionada con las normas.

3.3.2 La ISO 27000 En La Actualidad

Según la página ISO27000.es17

, la 27000 es realmente una serie de estándares. Los rangos de nume-

ración reservados por ISO van de 27000 a 27019 y de 27030 a 27044.

• ISO 27000: En fase de desarrollo; su fecha prevista de publicación es Noviembre de

2008. Contendrá términos y definiciones que se emplean en toda la serie 27000. Esta norma

está previsto que sea gratuita, a diferencia de las demás de la serie, que tendrán un coste.

• ISO 27001: Publicada el 15 de Octubre de 2005. Es la norma principal de la serie y con-

tiene los requisitos del sistema de gestión de seguridad de la información. Tiene su origen en

la BS 7799-2:2002 y es la norma con arreglo a la cual se certifican por auditores externos

los SGSI de las organizaciones. Desde el 28 de Noviembre de 2007, esta norma está publi-

cada en España como UNE-ISO/IEC 27001:2007 y puede adquirirse online en AENOR.

Otros países donde también está publicada en español son, por ejemplo, Colombia, Vene-

zuela y Argentina.

• ISO 27002: Desde el 1 de Julio de 2007, es el nuevo nombre de ISO 17799:2005, man-

teniendo 2005 como año de edición. Es una guía de buenas prácticas que describe los objeti-

vos de control y controles recomendables en cuanto a seguridad de la información. No es

certificable. Contiene 39 objetivos de control y 133 controles, agrupados en 11 dominios.

Como se ha mencionado en su apartado correspondiente, la norma ISO27001 contiene un

anexo que resume los controles de ISO 27002:2005. En España, aún no está traducida (pre-

16

W3J.COM. (s.f.). W3J- Corporate Governance: News, plans & Documentation. Recuperado el 27 de mayo de 2008, de

http://www.w3j.com/5/s3.instone.html 17

ISO 27000.es. (s.f.). ISO 27000.es. Recuperado el 03 de Mayo de 2008, de http://www.iso27000.es/iso27000.html


Página 31


visiblemente, a lo largo de 2008). Desde 2006, sí está traducida en Colombia (como ISO

17799) y, desde 2007, en Perú (como ISO 17799; descarga gratuita).

• ISO 27003: En fase de desarrollo; su fecha prevista de publicación es Mayo de 2009.

Consistirá en una guía de implementación de SGSI (Sistema de Gestión de la Seguridad de

la Información) e información acerca del uso del modelo PDCA (Plan, Do, Check, Act) y de

los requerimientos de sus diferentes fases. Tiene su origen en el anexo B de la norma

BS7799-2 y en la serie de documentos publicados por BSI a lo largo de los años con reco-

mendaciones y guías de implantación.

• ISO 27004: En fase de desarrollo; su fecha prevista de publicación es Noviembre de

2008. Especificará las métricas y las técnicas de medida aplicables para determinar la efica-

cia de un SGSI y de los controles relacionados. Estas métricas se usan fundamentalmente

para la medición de los componentes de la fase “Do” (Implementar y Utilizar) del ciclo

PDCA.

• ISO 27005: En fase de desarrollo; su fecha prevista de publicación es Mayo de 2008.

Consistirá en una guía de técnicas para la gestión del riesgo de la seguridad de la informa-

ción y servirá, por tanto, de apoyo a la ISO27001 y a la implantación de un SGSI. Recogerá

partes de ISO/IEC TR 13335.

Beneficios

• Establecimiento de una metodología de gestión de la seguridad clara y estructurada.

• Reducción del riesgo de pérdida, robo o corrupción de información.

• Los clientes tienen acceso a la información a través medidas de seguridad.

• Los riesgos y sus controles son continuamente revisados.


Página 32

• Confianza de clientes y socios estratégicos por la garantía de calidad y confidencialidad

comercial.

• Las auditorías externas ayudan cíclicamente a identificar las debilidades del sistema y las

áreas a mejorar.

• Posibilidad de integrarse con otros sistemas de gestión (ISO 9001, ISO 14001, OHSAS

18001).

• Continuidad de las operaciones necesarias de negocio tras incidentes de gravedad.

• Conformidad con la legislación vigente sobre información personal, propiedad intelectual

y otras.

• Imagen de empresa a nivel internacional y elemento diferenciador de la competencia.

• Confianza y reglas claras para las personas de la organización.

• Reducción de costes y mejora de los procesos y servicio.

• Aumento de la motivación y satisfacción del personal.

• Aumento de la seguridad en base a la gestión de procesos en vez de en la compra sistemá-

tica de productos y tecnologías.


Página 33


Ilustración 2. ISO 27000

Fuente: www.iso27000.es

3.4. ¿QUÉ ES PMBOK?

Es un estándar reconocido internacionalmente desarrollado por el PMI (Project Management Insti-

tute). Actualmente la versión más reciente es el PMBOK tercera edición, publicada en el 2004. Este

provee los fundamentos de administración de proyectos que son aplicables para un amplio rango de

proyectos, incluyendo la construcción, software, ingeniería, etc.

3.4.1. Componentes Del PMBOK

El PMBOK definió 5 grupos de procesos básicos. Estos procesos se superponen e interactúan a

través de un proyecto o fase. Los procesos se describen en términos de:

1. Entradas (documentos, planes, diseños, etc).

2. Herramientas y Técnicas (mecanismos aplicados a las entradas).

3. Salida (documentos, productos, etc)


Página 34

3.4.2. Grupos De Procesos De PMBOK

Estos grupos de procesos según el PMBOK, tercera edición18

:

1. Inicio

Se compone de procesos que facilitan la autorización formal para comenzar un nuevo pro-

yecto o una fase del mismo. Además, durante el proceso de iniciación se refina la descrip-

ción del alcance inicial y los recursos que la organización está dispuesta a invertir. Si aún no

hubiera sido designado, se elegirá al director del proyecto. También se documentarán las

restricciones y asunciones iniciales.

El Grupo de Procesos de Iniciación (Ilustración 3) inicia un proyecto o fase del proyecto, y

la salida define la finalidad del proyecto, identifica los objetivos y autoriza al director del

proyecto a iniciar el proyecto. Estos procesos son:

Ilustración 3. Grupo de Procesos de Iniciación

Fuente: Guía del PMBOK®

18

Project Management Institute, Inc. (2006). Project Management Institute - Santafe De Bogotá Chapter. Recuperado el

30 de Mayo de 2008, de

http://www.pmicolombia.org/faq.htm#Beneficios %20individuales%20de%20la%20Certificación.


Página 35


1. Desarrollar el acta de constitución del proyecto.

2. Desarrollar el enunciado del alcance del proyecto (Preliminar).

2. Planificación

El Grupo de Procesos de Planificación ayuda a recoger información de varias fuentes de di-

verso grado de completitud y confianza. Los procesos de planificación desarrollan el plan de

gestión del proyecto. Estos procesos también identifican, definen y maduran el alcance del

proyecto, el coste del proyecto y planifican las actividades del proyecto que se realizan de-

ntro del proyecto. Los cambios significativos durante el ciclo de vida del proyecto provocan

la necesidad de reiterar uno o más de los procesos de planificación y, posiblemente, alguno

de los procesos de iniciación.

El equipo del proyecto debe implicar a los interesados en la planificación del proyecto, ya

que éstos tienen habilidades y conocimientos que pueden ser aprovechados en el desarrollo

del plan de gestión del proyecto y en cualquiera de los planes subsidiarios. El equipo del

proyecto debe crear un entorno en el cual los interesados puedan contribuir apropiadamente.

Según la ilustración 4, los procesos que constituyen el grupo de procesos de planificación son:

1. Desarrollar el Plan de Gestión del Proyecto

2. Planificación del Alcance

3. Definición del Alcance

4. Crear EDT

5. Definición de las Actividades

6. Establecimiento de la Secuencia de las Actividades

7. Estimación de Recursos de las Actividades

8. Estimación de la Duración de las Actividades


Página 36

9. Desarrollo del Cronograma

10. Estimación de Costes

11. Preparación del Presupuesto de Costes

12. Planificación de Calidad

13. Planificación de los Recursos Humanos

14. Planificación de las Comunicaciones

15. Planificación de la Gestión de Riesgos

16. Identificación de Riesgos

17. Análisis Cualitativo de Riesgos

18. Análisis Cuantitativo de Riesgos

19. Planificación de la Respuesta a los Riesgos

20. Planificar las Compras y Adquisiciones

21. Planificar la Contratación


Página 37


Ilustración 4. Grupo de Procesos de Planificación



Página 38

3. Ejecución

El Grupo de Procesos de Ejecución se compone de los procesos utilizados para completar el

trabajo definido en el plan de gestión del proyecto a fin de cumplir con los requisitos del

proyecto. Este Grupo de Procesos implica coordinar personas y recursos, así como integrar y

realizar las actividades del proyecto, de acuerdo con el plan de gestión del proyecto. Este

Grupo de Procesos también aborda el alcance definido en el enunciado del alcance del pro-

yecto e implementa los cambios aprobados (vea la ilustración 5).

Entre los procesos que componen este grupo están:

1. Dirigir y Gestionar la Ejecución del Proyecto

2. Realizar Aseguramiento de Calidad

3. Adquirir el Equipo del Proyecto

4. Desarrollar el Equipo del Proyecto

5. Distribución de la Información

6. Solicitar Respuestas de Vendedores

7. Selección de Vendedores


Página 39


Ilustración 5. Grupo de Procesos de Ejecución


4. Seguimiento y Control

El Grupo de Procesos de Seguimiento y Control se compone de aquellos procesos realizados para

observar la ejecución del proyecto de forma que se puedan identificar los posibles problemas opor-

tunamente y adoptar las acciones correctivas, cuando sea necesario, para controlar la ejecución del

proyecto. El beneficio clave de este Grupo de Procesos es que el rendimiento del proyecto se obser-

va y se mide regularmente para identificar las variaciones respecto del plan de gestión del proyecto.

También incluye controlar los cambios y recomendar acciones preventivas como anticipación de

posibles problemas.

El Grupo de Procesos de Seguimiento y Control incluye los siguientes procesos de dirección de

proyectos:

1. Supervisar y Controlar el Trabajo del Proyecto

2. Control Integrado de Cambios

3. Verificación del Alcance

4. Control del Alcance


Página 40

5. Control del Cronograma

6. Control de Costes

7. Realizar Control de Calidad

8. Gestionar el Equipo del Proyecto

9. Informar el Rendimiento

10. Gestionar a los Interesados

11. Seguimiento y Control de Riesgos

12. Administración del Contrato


Página 41


Ilustración 6. Grupo de Procesos de Seguimiento y Control



Página 42

5. Cierre

El Grupo de Procesos de Cierre incluye los procesos utilizados para finalizar formalmente todas las

actividades de un proyecto o de una fase de un proyecto, entregar el producto terminado a terceros o

cerrar un proyecto cancelado. Este Grupo de Procesos, una vez completado, verifica que los proce-

sos definidos se completan dentro de todos los Grupos de Procesos para cerrar el proyecto o una

fase del proyecto, según corresponda, y establece formalmente que se ha finalizado un proyecto o

fase del proyecto.

El Grupo de Procesos de Cierre incluye los siguientes procesos de dirección de proyectos (Ver ilus-

tración 7):

Ilustración 7. Grupo de Procesos de Cierre



Página 43


3.5. ¿QUÉ ES PRINCE?

Prince2 es un método de administración de proyectos se centra en la organización, la gestión y el

control. Fue elaborado inicialmente en 1989 por la CCTA (Agencia Central de Computadoras y

Telecomunicaciones) en el Reino Unido como un estándar para la administración de proyectos de

Tecnologías de la comunicación y hoy en día es ampliamente utilizado en este país para la gerencia

de proyectos. La versión más reciente de PRINCE2 es una propuesta generalizada para la adminis-

tración de proyectos, como proyectos de tecnología.

PRINCE2 (Proyectos en ambientes controlados), está basado en procesos, dando adaptación y cam-

bios escalables hacia la gerencia eficaz de proyectos. Cada uno de los procesos se define con entra-

das y salidas, objetivos a cumplir, y actividades que se realizaran.

Esta metodología divide los proyectos en etapas más pequeñas y por ende más manejables para

poder tener un control eficiente de los recursos y la supervisión del progreso. PRINCE2 está basado

en el producto, lo que quiere decir que todos lo que se planea dentro del marco del proyecto se cen-

tra en entregar resultados y no sólo en la elaboración de un cronograma. Es dirigido por un caso de

negocio, el cual describe la justificación, compromiso y el análisis hecho para determinar los entre-

gables deseados o el resultado.

3.5.1 La Metodología De PRINCE2

Según el artículo “How PRINCE2 Can Complement PMBOK and Your PMP”19

, PRINCE2 no pre-

tende ser tan amplio como el PMBOK. PRINCE2 se basa en los principios del PMBOK, como

cualquier metodología de gestión de proyectos debe ser. PRINCE2 extracte y se centra en los ele-

mentos (los "componentes") que se identifican como cruciales para el éxito de la evaluación y la

realización de un proyecto.

19

Siegelaub, Jay M. «PRINCE2 Download Centre.» PRINCE2 Download Centre. http://www.prince2.com/prince2-

downloads.asp (último acceso: 20 de 07 de 2008).


Página 44

Además, los proyectos de PRINCE2 se dividen en etapas, al igual que las fases del modelo de pro-

cesos del PMBOK. Por lo tanto PRINCE2 define por separado 45 sub-procesos y organiza estos

procesos en ocho de la siguiente manera:

1. Emprender un proyecto (SU – Starting Up a Project)

Establece un control de inicio para el proyecto. Esto ocurre una vez en el ciclo de vida del

proyecto, proporcionando las bases para la gestión de proyectos y su supervisión, evalua-

ción y viabilidad. Este proceso crea la Junta del proyecto, y asegura que las necesidades

de recursos se entiendan y se aseguren para la primera etapa, "el inicio de un proyecto".

2. Dirección de un Proyecto (DP – Directing a Project)

Opera en todo el proyecto por lo tanto interactúa con muchos de los otros procesos, y de-

fine las responsabilidades de la Junta del proyecto en sus funciones de supervisión del

proyecto. Proporciona los mecanismos para autorizar el proyecto, la aprobación de la

continuidad en la finalización de cada etapa, y el cierre del proyecto (todos sobre la base

del Business Case). Es el marco para el suministro de insumos al director del proyecto, la

recepción de las solicitudes del director de proyectos de información y asistencia, y la

toma de decisiones. Este es el único proceso en el que la Junta del proyecto está activo

(distinto de "Iniciar un proyecto," cuando la Junta se formó). Todos los demás procesos

se guían por el proyecto y directores de equipo.

3. Iniciar un proyecto (IP – Initiating a Project)

Ocurre una vez en el ciclo de vida del proyecto. Se establece el punto de vista de la forma

en que el proyecto global debe gestionarse, y establece esto bajo un "contrato" llamado el

Documento de Iniciación del Proyecto (PID). La intención del PID es proporcionar una

comprensión común de los elementos críticos del proyecto (similar a los resultados de

PMBOK del proceso de Planificación). También exige el compromiso de los recursos.

4. Controlando una fase (CS – Controlling a Stage)

Proporciona orientación al Gerente del Proyecto en la gestión del proyecto en el día a día.

Incluye: autorización de trabajo y recepción de los trabajos; cuestión y la gestión del

cambio; recolección del estado, análisis y presentación de informes; Examen de viabili-


Página 45


dad; medidas correctivas; y escalamiento de las preocupaciones a la Junta del proyecto y

otros recursos. Este proceso es iterativo, y se repite para cada fase de desarrollo del pro-

yecto.

5. Gestión de la entrega del producto (MP – Managing Product Delivery)

Es el mecanismo de los ejecutantes de la labor técnica (equipos, personas y contratistas)

de llegar a un acuerdo sobre el trabajo a realizar, informe sobre los progresos, completar

la labor, y la devolución de este. Ocurre con tanta frecuencia como los paquetes de traba-

jo que están autorizados.

6. Gestión de los límites de la fase (SB – Managing Stage boundaries)

Garantiza que el trabajo definido en la etapa se ha completado, se proporciona informa-

ción a la Junta del Proyecto para evaluar la viabilidad actual del proyecto, desarrolla pla-

nes y obtiene la autorización para la próxima etapa de trabajo, registros y las lecciones

aprendidas.

7. Cierre del proyecto (CP - Closing a Project)

Se cierra el proyecto, ya sea porque el cierre es provocado por la finalización del trabajo,

o por la terminación prematura. En cualquier caso, "Clausura" recoge las lecciones apren-

didas y las experiencias de proyectos de la organización registradas. Para completar su

labor, su objetivo es garantizar que: el trabajo se ha completado para la satisfacción del

Cliente y de la gerencia, todos los productos previstos se han entregado y se han acepta-

do por el cliente, y los acuerdos para el soporte y la operación de los productos del pro-

yecto están establecidos.

8. Planificación (PL - Planning)

Es el proceso común de muchos otros procesos en PRINCE2. Los planes son producidos

por la identificación de resultados, actividades y los recursos necesarios para crear el pro-

yecto, y la gestión y los requerimientos de calidad - todo ello a un nivel compatible con el

control de los requerimientos señalados en el PID.


Página 46

La gestión de proyectos es una disciplina compleja y sería un error suponer que la aplicación ciega

de PRINCE2 se traducirá en el éxito del proyecto. Del mismo modo, sería erróneo suponer que

todos los aspectos de PRINCE2 serán aplicables a cada proyecto. Por esta razón cada proceso tiene

una nota sobre la escalabilidad. Esto proporciona orientación al director del proyecto (y otras perso-

nas involucradas en el proyecto) en cuanto a qué parte del proceso aplicar. El aspecto positivo de

esto es que PRINCE2 puede adaptarse a las necesidades de un determinado proyecto.

3.6. ISO 12207

Según la página de ISO20

, ISO/IEC 12207:2008 establece un marco común para los procesos de

ciclo de vida del software, con una terminología bien definida, que puede ser referenciado por la

industria del software. Contiene procesos, actividades y tareas que han de aplicarse durante la ad-

quisición de un producto de software o servicio y durante el suministro, el desarrollo, operación,

mantenimiento y eliminación de productos de software, tanto si éstos se realizan internamente o

externamente en una organización. Los aspectos de definición del sistema necesarios para ofrecer el

contexto para los productos de software y servicios están incluidos.

ISO / IEC 12207:2008 establece también un proceso que puede ser empleado para la definición,

control y mejora de software de procesos de ciclo de vida.

3.6.1. Procesos Principales De La ISO 12207

Las actividades que pueden ser realizadas, según la presentación realizada en la Universidad De

Castilla21

sobre mantenimiento de software, durante el ciclo de vida del software se agrupan en

cinco procesos principales, ocho procesos de soporte, y cuatro procesos organizativos, así como el

proceso de adaptación.

20

International Organization For Standardization. (s.f.). ISO/IEC 12207:2008. Recuperado el 25 de 04 de 2008, de

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43447

21

Francisco Ruiz, M. P. (2000). Grupo Alarcos - Universidad De Castilla - La Mancha. Recuperado el 26 de Mayo de

2008, de http://alarcos.inf-cr.uclm.es/per/fruiz/cur/mso/trans/s10.pdf


Página 47


Ilustración 8. Grupo de Procesos de ISO 12207

Fuente: Presentación Mantenimiento del Software - Francisco Ruiz, Macario Polo

UNIVERSIDAD DE CASTILLA-LA MANCHA

Procesos Del Ciclo De Desarrollo

1. Proceso de adquisición. Este proceso comienza definiendo la necesidad de adquirir un

sistema o un producto software y continúa con la preparación y publicación de la soli-

citud de propuestas, la selección de un suministrador y la gestión de los procesos de

adquisición hasta la aceptación del producto.

2. Proceso de suministro. Este proceso puede iniciarse bien por una decisión de preparar

una propuesta para responder a una petición de un adquiriente, bien por la firma de un

contrato con el adquiriente para proporcionar el producto software. El proceso continúa

con la identificación de los procedimientos y recursos necesarios para gestionar y ase-

gurar el proyecto, incluyendo el desarrollo de los planes del proyecto y la ejecución de

los planes hasta la entrega del producto software.


Página 48

3. Proceso de desarrollo. Este proceso contiene las actividades para el análisis de requi-

sitos, diseño, codificación, integración, pruebas, e instalación y aceptación relativas al

software. El desarrollador selecciona y realiza, o presta apoyo, a las siguientes activi-

dades de acuerdo con el contrato.

Las principales actividades que lo forman son:

• Análisis de los requisitos

• Diseño de la arquitectura

• Diseño detallado

• Codificación y pruebas

• Integración

• Prueba de cualificación

• Instalación

• Soporte a la aceptación

4. Proceso de operación: (también llamado explotación). Este proceso abarca la opera-

ción del software y el soporte a usuarios. Debido a que la operación del software se in-

tegra en la operación del sistema, las actividades y tareas del proceso de operación se

refieren al sistema.

5. Proceso de mantenimiento. Este proceso se activa cuando el software sufre modifica-

ciones de código o de documentación asociada debido a un error, una deficiencia, un

problema o la necesidad de mejora/adaptación.

Procesos de apoyo del ciclo de vida

Según el documento electrónico del curso “Marco de evaluación EFOM – Basado en la

norma internacional ISO 12207”22

, un proceso de apoyo es el que apoya a los demás proce-

sos y garantiza el éxito y la calidad del producto software desarrollado.

22

López Novella, M. Á., Sánchez de la Nieta, L. G., Parras Cobo, M. J., & Fernández Fernández, R. M. (2005 -2006).

Marco de evaluación EFOM – Basado en la norma internacional ISO 12207.


Página 49


1. Proceso de documentación. Define las actividades para el registro de la infor-

mación producida por un proceso o actividad del ciclo de vida.

2. Proceso de gestión de la configuración. Define las actividades para identificar

y establecer las líneas bases fundamentales para el desarrollo de elementos soft-

ware, gestión de versiones, variante, en general actividades para el control del

cambio.

3. Proceso de aseguramiento de la calidad. Define las actividades para verificar

que los productos software cumplen con los requisitos especificados por el usua-

rio y se ajustan a los planes establecidos. El aseguramiento de la calidad puede

realizarse utilizando el resultado obtenido en otros procesos como el de apoyo,

verificación, validación, revisiones conjuntas, auditorías, etc.

4. Proceso de verificación. Define las actividades de verificación de los requisitos

en cuánto a que éstos sean completos y correctos y además que cumplan con las

condiciones establecidas en fases previas.

5. Proceso de validación. En este proceso de definen las actividades para asegurar

que el software final contempla todos los requisitos previos para su uso.

6. Proceso de revisiones conjuntas. Define las actividades para evaluar el estado y

productos de una actividad.

7. Proceso de auditoría. Define las actividades para determinar el cumplimiento de

los requisitos, planes y contrato. Este proceso puede ser empleado por dos partes

cualesquiera, donde una parte (la auditora) audita los productos software o activi-

dades de otra parte (la auditada).

8. Proceso de solución de problemas. Define un proceso para analizar y eliminar

los problemas (incluyendo las no conformidades) que sean descubiertos durante

la ejecución del proceso de desarrollo, operación, mantenimiento u otros proce-

sos, de esta manera se asegura que todos los problemas que surgen se solucionan.


Página 50

Procesos organizativos del ciclo de vida

Según el documento electrónico del curso “Marco de evaluación EFOM – Basado en la

norma internacional ISO 12207”23

, estos procesos se emplean por una organización para es-

tablecer e implementar una infraestructura constituida por procesos y personal asociados al

ciclo de vida, ayudan a mejorar la efectividad de la organización.

1. Proceso de gestión. Define las actividades básicas de gestión de los procesos du-

rante el ciclo de vida.

2. Proceso de infraestructura. Define las actividades básicas para establecer la in-

fraestructura necesaria para los procesos: hardware, software, instalaciones, nor-

mas, etc.

3. Proceso de mejora. Define las actividades básicas para controlar, valorar, medir

los procesos del ciclo de vida.

4. Proceso de formación. Define las actividades para mantener al personal forma-

do.

3.7. ¿QUÉ ES CMMI / CMM?

CMMI, “es un proceso enfocado en la mejora que proporciona a las organizaciones los elementos

esenciales para la eficacia de los procesos. Se puede utilizar para guiar el proceso de mejora a través

de un proyecto, una división, o de toda una organización”24

. Este estándar ayuda a mejorar o a eva-

luar 22 áreas de proceso que integran desarrollo de software e ingeniería de sistemas (CMMI-

SE/SW) y 25 en la que cubre también integración de producto (CMMI-SE/SW/IPPD).

23

Ibid. 24

Software Engineering Institute. Software Engineering Institute-Carnegie Mellon. 2008.

http://www.sei.cmu.edu/cmmi/general/index.html (último acceso: 18 de Marzo de 2008).


Página 51


A partir de noviembre de 1986 el SEI (Software Engineering Institute), como requerimiento del

Gobierno Federal de los Estados Unidos de América, desarrolló una primera definición de un mode-

lo de madurez de procesos en el desarrollo de software, que se publicó en septiembre de 1987. Este

trabajo evolucionó al modelo CMM o SW-CMM (CMM for Software), cuya última versión (v1.1)

se publicó en febrero de 1993.

3.7.1. Características de CMMI / CMM

Este modelo establece un conjunto de prácticas o procesos clave agrupados en Áreas Clave de Pro-

ceso (KPA - Key Process Area). Para cada área de proceso define un conjunto de buenas prácticas

que habrán de ser:

1. Definidas en un procedimiento documentado

2. Provistas (la organización) de los medios y formación necesarios

3. Ejecutadas de un modo sistemático, universal y uniforme (institucionalizadas)

4. Medidas

5. Verificadas

A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de modo que una orga-

nización que tenga institucionalizadas todas las prácticas incluidas en un nivel y sus inferiores, se

considera que ha alcanzado ese nivel de madurez.

3.7.2. Niveles de Madurez de CMMI

Los niveles son:

1 - Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el de-

sarrollo 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

mayoría de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi

siempre retrasos y sobrecostos. El resultado de los proyectos es impredecible.


Página 52

2 - Repetible. En este nivel las organizaciones disponen de unas prácticas institucionaliza-

das de gestión de proyectos, existen unas métricas básicas y un razonable seguimiento de la

calidad. La relación con subcontratistas y clientes está gestionada sistemáticamente.

3 - Definido. Además de una buena gestión de proyectos, a este nivel las organizaciones

disponen de correctos procedimientos de coordinación entre grupos, formación del perso-

nal, técnicas de ingeniería más detallada y un nivel más avanzado de métricas en los proce-

sos. Se implementan técnicas de revisión por pares (peer reviews).

4 - Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de

métricas significativas de calidad y productividad, 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.

5 - Optimizado. La organización completa está volcada en la mejora continua de los proce-

sos. Se hace uso intensivo de las métricas y se gestiona el proceso de innovación.

Así es como el modelo CMM establece una medida del progreso, conforme al avance en

niveles de madurez. Cada nivel a su vez cuenta con un número de áreas de proceso que de-

ben lograrse. El alcanzar estas áreas o estadios se detecta mediante la satisfacción o insatis-

facción de varias metas claras y cuantificables. Con la excepción del primer nivel, cada uno

de los restantes Niveles de Madurez está compuesto por un cierto número de Áreas Claves

de Proceso, conocidas a través de la documentación del CMM por su sigla inglesa: KPA.

Cada KPA identifica un conjunto de actividades y prácticas interrelacionadas, las cuales

cuando son realizadas en forma colectiva permiten alcanzar las metas fundamentales del

proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: Gestión, Organizacional e In-

geniería.

Las prácticas que deben ser realizadas por cada área Clave de Proceso están organizadas en

5 Características Comunes, las cuales constituyen propiedades que indican si la implemen-

tación y la institucionalización de un proceso clave es efectivo, repetible y duradero.


Página 53


Estas 5 características son: i)Compromiso de la realización, ii) La capacidad de realización,

iii) Las actividades realizadas, iv) Las mediciones y el análisis, v) La verificación de la im-

plementación.

3.7.3. CMM En Las Organizaciones

Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una guía útil para

orientar sus esfuerzos. Además, el SEI proporciona formación a evaluadores certificados (Lead

Assesors) capacitados para evaluar y certificar el nivel CMM en el que se encuentra una organiza-

ción. Esta certificación es requerida por el Departamento de Defensa de los Estados Unidos, pero

también es utilizada por multitud de organizaciones de todo el mundo para valorar a sus subcontra-

tistas de software.

Se considera típico que una organización dedique unos 18 meses para progresar un nivel, aunque

algunas consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso in-

tenso de la dirección.

Como consecuencia, muchas organizaciones que realizan funciones de factoría de software o, en

general, outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno de

sus niveles. Esto explica que uno de los países en el que más organizaciones certificadas existan sea

India, donde han florecido las factorías de software que trabajan para clientes estadounidenses y

europeos.

3.7.4. Qué es el 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:

1. Ingeniería (7)

2. Proyectos (5)

3. Organizativas (6)


Página 54

No utiliza niveles de madurez generales sino que en cada área de proceso una organización puede

alcanzar un determinado nivel de madurez.

3.7.5. Otros Modelos de CMM

IPD-CMM

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 pu-

blicarse este en el año 2000.

SSE-CMM

El System Security Engineering Capability Maturity Model o Modelo de Capacidad y

Madurez en la Ingeniería de Seguridad de Sistemas es un modelo derivado del CMM y que

describe las características esenciales de los procesos que deben existir en una organización

para asegurar una buena seguridad de sistemas.

Ha sido desarrollado por la "International 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.

Nació a partir de 1993 bajo los auspicios de la Agencia Nacional 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 versión data de 1997 y la actual (v3.0) fue

publicada en junio de 2003.

Pretende servir como:

1. Herramienta para que las organizaciones evalúen las prácticas de ingeniería de seguri-

dad y definan mejoras a las mismas.

2. Mecanismo estándar para que los clientes puedan evaluar la capacidad de los provee-

dores de ingeniería de seguridad.


Página 55


3. 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 función de los

niveles de madurez, sino que define 22 áreas para cada una de las cuales se puede alcanzar

un nivel en función del cumplimiento de unas "características comunes” Existen 11 áreas de

procesos de ingeniería y otras 11 dedicadas a la gestión de proyectos y organización. El

método de evaluación se denomina SSAM (SSE-CMM Appraisal Method).

3.8. ¿QUE ES EL BALANCE SCORECARD?

El Balanced Scorecard ó Tablero Integral de Mando es una herramienta para ejecutar y supervisar la

estrategia de la organización utilizando una combinación de indicadores financieros y no financie-

ros. Está diseñado para traducir la visión y estrategia en objetivos y medidas en cuatro equilibrado

perspectivas: financiera, clientes, procesos de negocio internos, aprendizaje y crecimiento. Da un

marco que garantiza que la estrategia se traduce en un conjunto de medidas de ejecución y resulta

una herramienta excelente para comunicar a toda la organización la visión de la compañía.

El Balanced Scorecard (BSC) fue originalmente desarrollado, por el profesor Robert Kaplan de

Harvard y el consultor David Norton de la firma Nolan & Norton, como un sistema de evaluación

del desempeño empresarial que se ha convertido en pieza fundamental del sistema estratégico de

gestión de las firmas alrededor del mundo.

Los directivos empresariales han acogido muy bien el BSC ya que les permite dar cumplimiento a

la visión de sus firmas y por la misma vía, la consecución de los objetivos y metas trazados en sus

planes estratégicos. Aunque la planeación estratégica es una herramienta muy usada en las empre-

sas, comúnmente la visión que se presenta en los planes estratégicos empresariales no se traduce en

términos operativos que permitan hacerla conocer al interior de toda la organización, algunos estu-

dios muestran que la visión es muy poco conocida entre la gerencia y los empleados

3.8.1. Objetivos del BSC

El BSC busca fundamentalmente complementar los indicadores tradicionalmente usados para eva-

luar el desempeño de las empresas, combinando indicadores financieros con no financieros, logran-


Página 56

do así un balance entre el desempeño de la organización día a día y la construcción de un futuro

promisorio, cumpliendo así la misión organizacional. Una buena estrategia no es suficiente: incluso

la estrategia mejor formulada fracasa si la organización no puede implementarla

BSC no es una moda más, es una herramienta que sin poner las operaciones normales de la empresa

en apuros, se complementa muy bien con lo ya construido en la organización.

3.8.2. Características del BSC

BSC es un modelo integrado porque utiliza las 4 perspectivas indispensables para ver una empresa

o área de la empresa como un todo, luego de dos investigaciones de 1 año de duración: una en los

Estados Unidos en 1990 y la otra en Europa en 1996, se ha podido establecer que son estas las 4

perspectivas básicas con las cuales es posible lograr cumplir la visión de una compañía y hacerlo

exitosamente.

Es balanceado porque busca el balance entre indicadores financieros y no financieros, el corto plazo

y el largo plazo, los indicadores de resultados y los de proceso y un balance entre el entorno y el

interior de la firma, ese es el concepto clave y novedoso sobre el cual se basa el nombre "Balanced

Scorecard" Sistema de indicadores balanceados. Lo importante aquí es que los indicadores de ges-

tión de una compañía estén balanceados, es decir existan tanto indicadores financieros como no

financieros, de resultado como de proceso y así sucesivamente.

Es una herramienta estratégica porque se trata de tener indicadores que están relacionados entre sí y

que cuenten la estrategia de la compañía por medio de un mapa de enlaces causa-efecto (indicado-

res de resultado e indicadores impulsores). La mayoría de empresas tienen indicadores aislados,

definidos independientemente por cada área de la compañía, los cuales buscan siempre fortalecer el

poder de las mismas, fortaleciendo cada vez más las islas o compartimientos (silos) funcionales.

Lo que requieren hoy en día las empresas son indicadores relacionados (cruzados) construídos entre

todas las áreas en forma consensuada, buscando siempre negociar los trade-offs no permitiendo que

un área sobresalga a costa de otra u otras áreas de la empresa.


Página 57


3.8.3. Las cuatro perspectivas del BSC

BSC conjuga los indicadores financieros y no financieros en cuatro diferentes perspectivas a través

de las cuales es posible observar la empresa en su conjunto.

La mayoría de sistemas de medición actuales en las compañías se caracterizan por estar casi o to-

talmente enfocados en los indicadores financieros. Cuando una compañía se enfoca principalmente

en indicadores financieros, en la mayoría de los casos, su desempeño corporativo se refleja en los

Reportes Financieros, los cuáles se basan en hechos pasados, colocan el énfasis en los resultados y

en el corto plazo.

Podríamos comparar los reportes financieros en una compañía con el marcador de un partido de

fútbol o de béisbol, simplemente nos dan un resultado, si ganamos o perdimos. Igualmente podría-

mos comparar los reportes financieros con manejar un avión con un solo instrumento (por ejemplo

la altitud). Nadie va a ganar un partido fijándose solamente en el marcador y tampoco llegará a su

destino exitosamente con un sólo instrumento de su panel de control.

La agrupación de la medición del desempeño en categorías generales (perspectivas) se considera a

la ayuda en la recopilación y selección de las medidas de rendimiento adecuados para la empresa.

Cuatro perspectivas generales han sido propuestas por el Balanced Scorecard:

1. Perspectivas financieras

Examina si la empresa la aplicación y ejecución de su estrategia están contribuyendo a la parte infe-

rior de la línea de mejora de la empresa. Representa los objetivos estratégicos a largo plazo de la

organización y, por tanto, incorpora los resultados tangibles de la estrategia en términos financieros

tradicionales. Objetivos financieros y medidas para la etapa de crecimiento se derivan del desarrollo

y el crecimiento de la organización que conducen a un aumento de los volúmenes de ventas, adqui-

sición de nuevos clientes, el crecimiento de los ingresos, etc. Mantener la etapa en el otro lado se

caracterizará por las medidas que evalúan la eficacia de la organización para gestionar sus opera-

ciones y costos, mediante el cálculo del retorno de la inversión, el retorno sobre el capital empleado,


Página 58

etc. Finalmente, la cosecha etapa se basará en el análisis de flujo de efectivo, con medidas tales

como períodos de amortización y volumen de ingresos. Algunas de las más comunes las medidas

financieras que se han incorporado en las perspectivas financieras son EVA, el crecimiento de los

ingresos, costos, márgenes de beneficio, el flujo de caja, ingresos netos de explotación, etc.

2. La perspectiva del cliente

Define la propuesta de valor que la organización se aplicará con el fin de satisfacer los clientes y,

por ende, generar más ventas a los más deseados (es decir, las más rentables) grupos de clientes.

Las medidas que sean seleccionados para la perspectiva del cliente deben medir tanto el valor que

se entrega al cliente (valor de posición) que puede implicar tiempo, la calidad, rendimiento y servi-

cio, y su coste y los resultados que vienen como resultado de esta propuesta de valor (por ejemplo,

la satisfacción del cliente, la cuota de mercado). La propuesta de valor puede ser centrado en uno de

los tres: la excelencia operativa, la intimidad del cliente o del producto de liderazgo, manteniendo

los niveles de umbral en los otros dos.

3. Perspectiva de proceso interno

Se refiere a los procesos que crean y entregar la propuesta de valor al cliente. Se centra en todas las

actividades y procesos clave necesarios a fin de que la empresa a sobresalir a proporcionar el valor

esperado por los clientes, tanto productiva y eficiente. Estas pueden incluir tanto a corto plazo y los

objetivos a largo plazo, así como la incorporación de innovadoras proceso de desarrollo con el fin

de estimular la mejora. Con el fin de identificar las medidas que corresponden para el proceso inter-

no de vista, Kaplan y Norton proponen ciertos grupos utilizando ese grupo similar valor en los pro-

cesos de creación de una organización. Los grupos para la perspectiva del proceso interno son las

operaciones de gestión (mediante la mejora de la utilización de activos, gestión de la cadena de

suministro, etc), gestión de clientes (mediante la expansión y profundización de las relaciones), la

innovación (por nuevos productos y servicios) y de reglamentación y social (mediante el estableci-

miento de buenas relaciones con los interlocutores externos).

4. Perspectiva del aprendizaje y de crecimiento.


Página 59


El aprendizaje y la perspectiva de crecimiento es el fundamento de toda estrategia y se centra en los

activos intangibles de una organización, principalmente en el interior de habilidades y capacidades

que son necesarias para apoyar la creación de valor de procesos internos. El aprendizaje y la pers-

pectiva de crecimiento tiene que ver con los puestos de trabajo (capital humano), los sistemas (in-

formación de capital), y el clima (organización de capital) de la empresa. Estos tres factores se re-

fieren a lo que Kaplan y Norton reclamación es la infraestructura que se necesita con el fin de per-

mitir unos objetivos ambiciosos en los otros tres perspectivas que deben alcanzarse. Esto, por su-

puesto, será en el largo plazo, ya que una mejora en el aprendizaje y la perspectiva de crecimiento

se requieren ciertos gastos que pueden disminuir a corto plazo los resultados financieros, al tiempo

que contribuyen a su éxito a largo plazo.


Página 60

III - PROCESO

4. LEVANTAMIENTO DE INFORMACIÓN

Durante esta fase del proyecto, se realizaron las siguientes actividades:

1. Estado del arte de los principales estándares: en esta primera actividad se realizó una con-

sulta y recopilación de información de los estándares ITIL, COBIT 4.0, PMBOK,

ISO27000, ISO12207, CMMI y Balance Scorecard, descritos en la sección anterior. Esto

con el fin de obtener un conocimiento general de estos y así tomar los aspectos más rele-

vantes que puedan aportar al desarrollo de la guía.

2. Elaboración de la entrevista a aplicar: se definió un grupo de preguntas para obtener in-

formación acerca de las herramientas utilizadas por los gerentes de proyectos para realizar

seguimiento y control de sus proyectos, además para saber que conocimiento tienen acer-

ca de COBIT 4.0 y que estándares para gerenciar proyectos usan comúnmente, entre otros

aspectos.(Ver anexo No. 2)

3. Diseño de la muestra objetivo: se definió la muestra objetivo con la ayuda del catedrático

Miguel Pinzón, egresado de la Universidad Nacional de Colombia y catedrático de la

Universidad Javeriana y Universidad Santo Tomás. Considerando el tipo de estudio que

fue planteado en el desarrollo de la propuesta, correspondiente a un proyecto de investiga-

ción se determinó que era apropiado usar el Método Aleatorio Simple. Según el diseño

de la muestra objetivo realizada junto con el profesor Miguel Pinzón (Ver anexo No. 3), se

determinó que el número de entrevistas que se deberían realizar era de 50.

4. Aplicación de las encuestas: Para realizar las encuestas se contactaron profesionales del

área de ingeniería, y que tuvieran experiencia en el área de gerencia de proyectos. Algu-

nos de los ingenieros que fueron contactados, fueron recomendados por la Directora del

Trabajo de Grado Ing. Jacqueline Becerra, y otros fueron contactados por medio de cono-

cidos de las autoras del trabajo de grado. Se llevaron a cabo las entrevistas en un periodo

de 4 semanas a un total de 50 profesionales, vinculados laboralmente a varias organiza-


Página 61


ciones, las cuales se realizaron personalmente en el lugar de trabajo de cada uno de ellos.

(Ver Anexo No. 4).

5. ANÁLISIS DE LA INFORMACIÓN RECOPILADA

En esta fase se realizaron varias actividades. Entre ellas se desarrolló un análisis de los resultados

de las entrevistas efectuadas, teniendo en cuenta los patrones de respuestas más comunes para rea-

lizar la tabulación y determinar cuáles son las tendencias más marcadas para cada una de las pre-

guntas de la entrevista. (Ver Anexo No. 5).

Después de obtener esta información y de acuerdo a las respuestas obtenidas las conclusiones

generales son:

Los gerentes de proyectos se apoyan en gran medida usando los lineamientos de la metodolog-

ía del PMBOK tanto en forma rigurosa como adaptándola a sus necesidades.

Las principales causas por las cuales los proyectos de tecnología fracasan según los entrevista-

dos, está relacionado con el alcance de proyecto, es decir por no limitarlo o por permitir cam-

bios en el mismo. Además se destacó la falta de planeación y la mala estimación de recursos y

riesgos.

Para el éxito de un proyecto se debe tener en cuenta una buena planeación, así como una buena

definición del alcance, evitando en lo posible cambiarlo durante el ciclo de vida del proyecto.

Otro aspecto a resaltar es la importancia de realizar seguimiento al desarrollo del proyecto y al

cumplimiento de los compromisos pactados.

Las características que debe tener un gerente de proyectos de Sistemas de Información y que

fueron las más destacadas por los entrevistados fueron: el liderazgo, conocimientos tanto técni-

cos como de gerencia, buena comunicación y relaciones interpersonales, entre otras.


Página 62

Un número considerable de entrevistados no cuenta con cursos o especializaciones respecto al

área de gerencia de proyectos, por lo tanto un gran porcentaje de ellos hace uso de su experien-

cia para desempeñarse como gerente de proyectos en Sistemas de Información.

La mayoría de los proyectos administrados por los entrevistados se han retrasado entre 1 a 2

meses, principalmente por mala definición del alcance del proyecto, por problemas con los

clientes y/o usuarios, mala definición de requerimientos y una inadecuada gestión de pruebas.

Un porcentaje importante de entrevistados cree que el concepto de auditoría de sistemas sería

un complemento ideal para la gerencia de proyectos, considerándose desde el inicio del pro-

yecto y desempeñando un papel de apoyo.

La mitad de los entrevistados aproximadamente conocen los conceptos básicos de COBIT pero

la mayoría no los utilizan en sus proyectos.

El análisis detallado de las respuestas de los encuestados y los resultados gráficos, se encuentran en

el anexo No. 6.

Adicionalmente, en esta etapa se realizó un estudio y análisis comparativo de la información recopi-

lada de las metodologías para la gerencia de proyectos, así como de las buenas prácticas para el

control y seguimiento de los procesos referentes al área de tecnología de la información. Para esto

se utilizaron los documentos de mapeo publicados por ISACA donde se realiza una comparación

entre COBIT 4.0 y los principales estándares como PMBOK, PRINCE2, ITIL y la ISO 17799. Para

cada uno de estos estándares se determinó cuáles procesos aplicaban y complementaban aspectos de

gestión de proyectos incluídos en el estándar COBIT 4.0, y obtener así lineamientos que permitieran

dar inicio al diseño de la guía propuesta como apoyo al seguimiento y control de la gerencia de

proyectos. (Ver anexo No. 7).

Además de esto, se llevo a cabo la revisión de guías existentes para tomarlas como referencia y

lograr desarrollar la guía a proponer dentro del trabajo. Dentro de las guías que se tuvieron en cuen-

ta se encuentran principalmente las propuestas en otros trabajos de grado.


Página 63


6. DISEÑO DE LA GUÍA

En el Anexo No. 8 se encuentra la guía desarrollada, cuyo diseño se encuentra descrito a continua-

ción, el cual se trabajó en dos frentes:

Análisis de los resultados de las entrevistas realizadas a una muestra de 50 Ingenieros cuyo

rol ha sido el de Gerente de Proyectos de Sistemas de Información.

Revisión y análisis del Objetivo de Control “P010: Administrar Proyectos” del estándar

COBIT 4.0 vs. las buenas prácticas: ITIL, PMBOK, ISO17799, PRINCE2.

Del primer análisis se identificaron los posibles siguientes criterios a tener en cuenta en el diseño

de la guía, a saber:

Definición del Alcance, Equipo de Trabajo, Tiempo, Riesgos y Presupuesto.

Definición y asignación de actividades e identificación de hitos.

Definir la metodología a utilizar para la gerencia de proyectos.

Llevar una documentación adecuada del proyecto.

Tener una buena comunicación con todos los involucrados en el proyecto.

Realizar seguimiento continuo a todas las actividades del proyecto.

Definición de políticas de seguridad de Información dentro del desarrollo del proyecto.

Del segundo análisis se obtuvieron los siguientes criterios a considerar tanto para PMBOK como

PRINCE2:

Los interesados en el desarrollo del proyecto

Definición del alcance del proyecto

Definición el plan Integral del Proyecto

Recurso Humano para el desarrollo del proyecto

Control de cambios para el proyecto


Página 64

Proceso de administración de la planeación

Definición del plan de calidad

Definición del plan de riesgos

Mecanismos de reportes. Monitoreo y seguimiento para el proyecto

Proceso de Cierre

Sin embargo, el comparativo con ITIL no considera entre otros los siguientes criterios

Los interesados en el desarrollo del proyecto

Definición del alcance del proyecto

Definición del plan de riesgos

Control de cambios para el proyecto

Y finalmente el comparativo entre COBIT contra la ISO 17799 no es considerada aplicada al am-

biente de la gerencia de Proyectos de Sistemas de Información.

Un tercer elemento que se consideró corresponde a los criterios presentados por PMBOK sobre

Seguimiento y Control enmarcados en:

1. Supervisar y Controlar el Trabajo del Proyecto

2. Control Integrado de Cambios

3. Verificación del Alcance

4. Control del Alcance

5. Control del Cronograma

6. Control de Costos

7. Realizar Control de Calidad

8. Gestionar el Equipo del Proyecto

9. Informar el Rendimiento

10. Gestionar a los Interesados

11. Seguimiento y Control de Riesgos

12. Administración del Contrato


Página 65


De acuerdo a lo anterior las autoras del Trabajo de Grado proponen los siguientes puntos de control

a considerar dentro de la guía:

Planeación: En este se tendrá en cuenta el seguimiento y control de las actividades planea-

das así como el control del cronograma de trabajo, seguimiento a los cambios efectuados y

su impacto en el desarrollo del proyecto de acuerdo a las condiciones inicialmente pacta-

das.

Gestión Financiera: En este se hará seguimiento y control de los recursos financieros asig-

nados al proyecto y su administración.

Recursos Humanos: se hará un control y seguimiento de la gestión del equipo de trabajo, se

validará la entrega de informes de rendimiento de las personas asignadas al proyecto, así

como el cumplimiento de las tareas asignadas dentro plazo establecido.

Comunicación: En este punto se verificará que el gerente realice las reuniones programadas

y deje un soporte documental de los acuerdos y compromisos adquiridos en cada una de es-

tas.

Riesgos: En este punto se verificará que el gerente haya identificado los riesgos que puedan

afectar el avance y desarrollo del proyecto y que se hayan contemplado en un plan de ges-

tión de riesgos el impacto, la probabilidad del riesgo y según esto se definan las acciones

preventivas y correctivas.

Seguridad: En este punto se validará que el gerente haya tenido en cuenta los aspectos de

seguridad física y seguridad de la información que puedan afectar al proyecto.

Calidad: En este punto se realizará el control y seguimiento de los conceptos relacionados

con el tema de calidad para el proyecto.

La guía se elaboró teniendo en cuenta que el seguimiento y control de un proyecto se debe realizar

desde el inicio hasta el cierre del mismo, evaluando los puntos de control descritos anteriormente.

Para cada uno de estos, se diseñaron tres listas de chequeo con preguntas que cubren las fases de

inicio, ejecución y cierre del proyecto. Se consideraron estas fases para realizar el seguimiento y

control de un proyecto debido a que no se quiere limitar la guía a las fases determinadas por algún


Página 66

estándar ya que lo que se busca es unir conceptos para elaborar una guía completa y que pueda ser

utilizada sin importar las buenas prácticas que cada gerente considere en su trabajo.

Para cada uno de los puntos de control se definió el alcance, el valor agregado y los riesgos que

pueden presentarse si no se tienen en cuenta. Estos tendrán un puntaje asignado como se ve en la

siguiente tabla:

PUNTOS DE CONTROL PUNTAJE

Planeación 20

Gestión Financiera 15

Recursos Humano 15

Comunicación 20

Riesgos 20

Seguridad 5

Calidad 5

El puntaje total e ideal es de 100 puntos. Para cada punto de control se asignó un puntaje depen-

diendo de su criticidad para el desarrollo del proyecto. En este caso los puntos de control con mayor

puntaje son: La planeación, debido a que es fundamental definir el alcance del proyecto y con base

a esto elaborar un plan de trabajo para poder llevar a cabo el proyecto de manera organizada y reali-

zar un adecuado seguimiento. El siguiente punto de control es el de la comunicación ya que es fun-

damental establecer canales de comunicación para intercambiar información relevante durante el

desarrollo del proyecto, llegar a acuerdos y establecer compromisos. Por último, el punto de control

con mayor puntaje es el de riesgos pues al identificarlos y controlarlos, es posible evitar que se con-

viertan en problemas reales que afecten la ejecución del proyecto.


Página 67


A los demás puntos de control se les asignó un puntaje más bajo, lo cual no significa que no tengan

mayor relevancia. En este caso, el punto de control referente a los recursos humanos tiene un pun-

taje de 15, puesto que se considera necesario contar con un equipo de trabajo competente para cum-

plir con los objetivos del proyecto, además de promover un ambiente de trabajo adecuado. Este

mismo puntaje se asignó al punto de control correspondiente al aspecto financiero, debido a que es

importante controlar los gastos e ingresos del proyecto para cuidar que el margen de utilidad no

disminuya.

Al siguiente punto de control denominado como seguridad se asignó 5 puntos, ya que es posible no

tener procedimientos formales que ayuden a resguardar la información que se utilice en el proyecto

y custodiar las áreas de trabajo, pero es elemental contar con ciertas precauciones de seguridad con

todo lo relacionado al proyecto. Por último, al punto de control correspondiente a la calidad también

se le asignó 5 puntos debido a que es importante asegurar que tanto la gestión del proyecto como el

producto que se va a entregar cumplan con los requisitos establecidos por la compañía y por el

usuario.

Por otra parte, el puntaje asignado para cada punto de control se dividió por cada fase del proyecto,

de la siguiente manera:

PUNTO DE CONTROL

(Puntaje)

FASES DEL PROYECTO

INICIO EJECUCIÓN CIERRE

Planeación (20) 10 5 5

Gestión Financiera (15) 7 4 4

Recursos Humanos (15) 6 6 3

Comunicación (20) 8 9 3

Riesgos (20) 10 7 3

Seguridad (5) 2 2 1

Calidad (5) 1 3 1


Página 68

Para la elaboración de las preguntas de cada lista de chequeo, se tomó el resultado del análisis reali-

zado en la fase de la metodología correspondiente al “Análisis de la información recopilada”, par-

tiendo principalmente de los conceptos contemplados en el objetivo de control “PO10:Administrar

Proyectos” del estándar COBIT 4.0 y los lineamientos descritos por el PMBOK que se relacionaron

con el análisis de los resultados de las entrevistas, y por último se revisó el estándar de la ISO

17799, el cual aunque no es un estándar para la administración de proyectos, aporta conceptos im-

portantes básicos de la seguridad de la información que se debe manejar dentro de los proyectos.

Como un valor agregado se contempló durante el diseño de la guía incluir un método de valoración

de la gestión del gerente del proyecto, y permitir de esta manera en forma cuantitativa saber si ha

sido eficiente o no. Para esto, se definió una tabla con rangos en la que se ubicará la calificación de

la gestión del gerente del proyecto quien podrá tener una visión de su desempeño para ir mejorando

en las siguientes etapas del proyecto y/o para futuros proyectos. Los rangos definidos son los si-

guientes:

CALIFICACIÓN RANGO

EXCELENTE 76-100

BUENA 51-75

REGULAR 26-50

DEFICIENTE 0-25

Según el número obtenido dentro del rango, se considera excelente porque la gestión del gerente

excede claramente el desempeño promedio realizando su trabajo oportuna y correctamente, así co-

mo realizando una adecuada documentación de las actividades realizadas, cumplimiento las metas

planeadas.

Por otro lado, la gestión del gerente se califica como buena cuando su desempeño se ubica en el

promedio, realizando todas sus funciones satisfactoriamente, sin aportar ningún valor agregado al

proyecto. Por el contrario, la calificación regular demuestra que existen falencias en la gestión del


Página 69


proyecto, que lo ubica por debajo del promedio pero pueden ser corregidas a través de un segui-

miento constante y efectivo de la realización de sus funciones.

Por último, la calificación deficiente indica que el gerente no obtuvo los resultados esperados,

ubicándose muy por debajo del promedio, lo cual requiere que el gerente revise su metodología para

determinar si es la adecuada para realizar una gestión apropiada.

Dependiendo de la calificación obtenida es recomendable revisar aquellos puntos de control donde

su respuesta fue no satisfactoria, para definir y ejecutar las acciones necesarias que permitan me-

jorar el desempeño y obtener mejores resultados.

Cabe anotar que esta definición de puntaje es de tipo experimental y está basada en el conocimien-

to adquirido durante el desarrollo del proyecto. Sin embargo, los mismos deberán ser reevaluados a

medida que se aplique la guía y se vaya obteniendo experiencia en el ejercicio, hasta llegar a definir

los rangos indicados o que sean óptimos para la aplicación de esta guía.

Los componentes de la guía descritos anteriormente se pueden ver en la siguiente gráfica:

Fuente: Autoras


Página 70

7. APLICACIÓN Y VALIDACIÓN

Para realizar la aplicación y validación de la guía, se contactaron a tres profesionales de Ingeniería

de Sistemas con experiencia en Gerencia de Proyectos, Jaime García Cepeda, Dora Ariza Aguilera

y Henry Cortés Contreras.

Jaime es Ingeniero de Sistemas de la Universidad Nacional de Colombia. Cuenta con un postgrado

Sistemas de Información en la Organización de la Universidad de los Andes. Su experiencia lo ha

llevado a ser coordinador de Proyectos del Banco de Occidente, especialista en Informática de

Pronta CFC, Gerente Nacional de Operaciones de La Fortaleza CFC, Director de Sistemas de Lea-

sing Colmena y Gerente de Integración Tecnológica Banco Caja Social, Director de Informática y

Planeación Superintendencia Bancaria de Colombia. Actualmente Socio y Gerente General de SKIT

Consulting y Catedrático de Pregrado y Postgrado de la Pontificia Universidad Javeriana.

Dora Alba es Ingeniera de Sistemas y Psicóloga de la Universidad Católica de Colombia. Cuenta

con una Especialización en Gerencia de Proyectos y un Master Executive en Gestión de Conoci-

miento en la Universidad EOI América de España. Es miembro del Project Management Institute

(PMI) y certificada PMP® Project Management Professional. Lleva acabo asesorías en Gestión de

Conocimiento, que incluyen la implementación de la metodología de Gestión de proyectos y de

Oficinas de Proyectos. Ha llevado a cabo esta asesoría en instituciones como Banco de Bogotá y

Ministerio de Educación Nacional, entre otras. Tiene experiencia de más de 18 años en el desarrollo

de proyectos de Tecnología en sectores diversos como la industria, la banca, el gobierno y las tele-

comunicaciones.

Henry Cortés es Ingeniero de Sistemas de la Universidad Autónoma de Colombia. Especialista en

Auditoría de Sistemas de Información y en Gerencia Informática de la EAN. Actualmente trabaja

en la oficina de Sistemas del Instituto Nacional de Medicina Legal y Ciencias Forenses. Catedrá-

tico de las Universidades Autónoma de Colombia y la Universidad Distrital Francisco Jóse de Cal-

das. Cuenta con una experiencia de más de 20 años en Sistemas especialmente en el sector público.


Página 71


A los tres profesionales se les dió una copia de la guía elaborada para que la aplicarán en un proyec-

to en curso y emitieran su concepto acerca de su contenido, forma y realizarán otras observaciones

que creyeran pertinentes. Para apoyar este proceso se diseño una encuesta para recoger sus opinio-

nes y observaciones de una manera más formal. (Anexo Número. 9).

Para el caso de la ingeniera Dora Ariza no fue posible aplicar la guía a un proyecto en curso debido

a sus múltiples ocupaciones. Por lo tanto se recibió retroalimentación en cuanto a la forma y el con-

tenido de la guía. Sus recomendaciones fueron las siguientes:

1. Incluir un punto de control relacionado con la calidad del proyecto. Este control verifica si

las métricas, estándares, procedimientos de la organización han sido seguidos de acuerdo

con un plan de calidad y si se han cumplido los requerimientos dados por el cliente.

2. Incluir el punto de control referente a la Administración de la Configuración que incluye la

parte de administración del cambio principalmente.

3. Considera importante tener en cuenta el grupo de procesos que propone el PMBOK co-

rrespondientes a inicio, planeación, ejecución, seguimiento y control, y cierre.

De las anteriores, se implementó la correspondiente al punto de control de calidad ya que se consi-

deró que la administración de configuraciones para el caso de gerencia de proyectos no es crítica,

porque esta es una función del líder del equipo de desarrollo de software. No obstante esto podría

desarrollarse en futuros trabajos.

Por otro lado, no se consideraron los grupos de procesos del PMBOK debido a que la guía no es una

materialización de un estándar en particular, sino la unión de diferentes buenas prácticas que en

conjunto se espera que aporten más que trabajando cada una por separado.

La encuesta diligenciada por Dora Ariza se encuentra en el anexo 10.

En cuanto a la validación realizada por el ingeniero Jaime García, una vez que fue aplicada la guía

se realizó una reunión para recoger sus opiniones, que fueron las siguientes:


Página 72

1. Se recomienda definir el alcance de la guía dentro de la misma.

2. Se recomienda no usar el término de puntos de control, ya que

son términos usados por auditores más no por gerentes.

3. Se recomienda realizar gráficas explicativas de como se encuentra

estructurada la guía así como tener un capitulo donde se narre su estructura.

4. Se recomienda ubicar al lector dentro de la guía, como por ejemplo con una gráfica

explicativa para saber en que etapa de ésta se encuentra.

5. Se recomienda reemplazar la columna "observaciones" por "planes de

acción” para que al final el gerente obtenga un plan de mejora a

partir de cada uno de estos planes.

Esta última recomendación no se tuvo en cuenta porque el propósito inicial de la guía no se definió

para recomendar acciones de mejora sino para realizar seguimiento y control, y como valor agrega-

do evaluar la gestión desempeñada, además la estructura de una lista de chequeo no contempla

realizar planes de acciones, pues estos por lo general se encuentran en los informes que se realizan

posteriormente. A pesar de esto, esta observación puede ser base para futuros trabajos.

La encuesta diligenciada por Jaime García se encuentra en el anexo 11.

Luego de que Jaime García aplicara la guía al proyecto “Medios Electrónicos Fase II”, su gestión

para este proyecto fue calificada como buena, de acuerdo a los rangos de calificación definidos en

la guía. Los resultados de esta aplicación se pueden ver en el anexo 12.

Además, la guía fue validada por Henry Cortés Contreras, quién también la aplicó a un proyecto

que actualmente está llevando a cabo. Sus recomendaciones fueron las siguientes:

1. Cambiar el puntaje asignado para cada punto de control así como el rango

asignado para la calificación correspondiente a “Excelente”.


Página 73


2. En los casos en que la calificación sea regular o deficiente, se deberían re-

comendar acciones correctivas.

3. Se debería poder parametrizar los rangos y puntajes de acuerdo a las nece-

sidades de cada compañía.

Las recomendaciones referentes a modificar los rangos y puntajes son importantes tenerlas en cuen-

ta para el desarrollo de futuros trabajos donde se automatice la guía de tal manera que se pueda

adecuar según las necesidades particulares de cada proyecto. De igual forma, como parte de un

trabajo futuro, se podrían generar acciones correctivas de acuerdo a las preguntas cuya respuesta fue

negativa. La encuesta diligenciada por Henry Cortés Contreras se encuentra en el anexo 13.

Luego de la aplicación de la guía en el proyecto “Observancia de Bases de Datos”, que realizó

Henry Cortés Contreras, su gestión para este proyecto fue calificada como excelente, de acuerdo a

los rangos de calificación definidos en la guía. Los resultados de esta aplicación se pueden ver en el

anexo 14.

Además, se utilizó como herramienta de validación una matriz de trazabilidad que permite verificar

si lo que se propuso inicialmente se cumplió, como se muestra a continuación:

OBJETIVO PLANTEADO CUMPLIMIENTO

Analizar tanto el nivel de conocimiento que

tienen los gerentes de proyectos de sistemas de

información acerca de las herramientas de con-

trol y seguimiento y de los estándares que pue-

dan apoyar estos procesos, como la forma de

desarrollo de estas actividades.

100%. Se llevó a cabo una consulta a una mues-

tra de ingenieros y con base en sus respuestas se

determinaron problemas presentes en los pro-

yectos como también posibles soluciones. Se

determinaron puntos de control a validar.

Identificar y analizar los objetivos de control de

cada uno de los dominios definidos por COBIT

4.0 que aporten al seguimiento y control de la

gerencia de proyectos.

100%. Se llevó a cabo una revisión de los están-

dares establecidos y se analizó el impacto de los

mismos según la buena practica definida por

COBIT 4.0


Página 74

Diseñar la guía que apoye al gerente de proyec-

tos de sistemas de información en los procesos

de seguimiento y control basados en el análisis

previo.

100%. Se elaboró la guía con base en la infor-

mación recopilada y analizada previamente.

Validar la guía propuesta en un escenario de

prueba específico, para poder realizar la evalua-

ción respectiva

100% Se facilitó la guía a tres profesionales,

quienes dieron la retroalimentación correspon-

diente y se aplicaron algunas de estas recomen-

daciones sujetas a la discreción de las autoras.

8. REFLEXIÓN METODOLÓGICA

La metodología planteada se cumplió y fue adecuada para la naturaleza del trabajo, ya que era de

carácter investigativo. Las fases que se definieron dentro de ésta apoyaron al desarrollo del trabajo

de una manera progresiva de tal manera que se logró cumplir cada objetivo planteado.


Página 75


9. RESULTADOS

Luego de realizar cada una de las actividades de las fases que componen el proceso metodológico

propuesto, se obtuvieron los siguientes resultados:

Levantamiento de Información: A partir de los estándares que se investigaron, se logró ob-

tener el marco teórico pertinente para el desarrollo de este trabajo de tipo investigativo,

además se recopiló información de aspectos importantes respecto a la gerencia de proyectos

por medio de la entrevista que se elaboró y aplicó para este fin.

Análisis de la información recopilada: El resultado de esta fase corresponde al análisis rea-

lizado respecto a los documentos que contenían el comparativo entre COBIT 4.0 y otros

estándares relevantes para este trabajo. También se examinaron los resultados obtenidos

luego de aplicar la entrevista a diferentes ingenieros que ejercieron el rol de gerente de

proyectos de sistemas de información. A partir de estos dos análisis se identificaron los cri-

terios importantes para tener en cuenta en el diseño de la guía.

Diseño de la guía: Con base a los resultados obtenidos en la fase anterior, se diseñó la guía

propuesta cuya estructura se puede ver más detalladamente en el numeral seis correspon-

diente al capítulo tres de este documento.

Validación y aplicación: En esta fase se obtuvo la guía diligenciada por parte de tres inge-

nieros que aportaron su experiencia para lograr validar la guía y por medio de una encuesta

se recogió de manera formal su opinión. A partir de esto se realizaron los cambios que se

consideraron dentro del alcance de la guía.


Página 76

10. RECOMENDACIONES

Luego de desarrollar este trabajo de grado y a partir de la retroalimentación recibida por parte de

los entrevistados en las fases de recopilación de información, validación y aplicación de la guía, se

consideró importante aclarar qué para hacer buen uso de la guía se debe tener en cuenta cuál es el

alcance de ésta y el procedimiento que se debe seguir para entender cómo se debe aplicar la guía.

Por otra parte, es fundamental tener claro que la guía se elaboró a partir de la combinación de dife-

rentes aportes de los estándares y buenas prácticas consultadas en las fases de levantamiento y aná-

lisis de la información, de esta forma la guía no se limita a un sólo estándar con el fin de que pueda

ser aplicada por cualquier gerente, sin importar que buenas prácticas siga o conozca.

También es importante tener cuenta que durante la fase de ejecución del proyecto, se puede diligen-

ciar más de una vez las listas de chequeo correspondientes a cada punto de control, con el ánimo de

evaluar en varias iteraciones la gestión del gerente en esta etapa del proyecto. Es fundamental que

entre cada repetición se tengan en cuenta las lecciones aprendidas en la(s) iteración(es) anterior(es).


Página 77


11. CONCLUSIONES

Existen campos de acción, como en este caso la gerencia de proyectos, que implican tener un

grado mínimo de conocimiento de diferentes disciplinas para poder realizar una gestión más

acertada y eficiente, apoyándose de buenas prácticas que provienen de diversas fuentes.

En Colombia, actualmente los gerentes de proyectos se apoyan principalmente en el estándar

PMBOK propuesto por el PMI, debido a esto fue necesario aclarar que la guía que se elaboró

no se limita sólo a este estándar sino por el contrario fue estructurada a partir del análisis reali-

zado de diferentes buenas prácticas.

Durante el transcurso de la investigación se encontró gran cantidad de información referente a

la gerencia de proyectos por lo que fue necesario aprender a identificar que información era re-

almente relevante y tenía fundamentos validos para así hacer uso de ésta en el desarrollo del

trabajo propuesto.

Para realizar el levantamiento de información con respecto a la opinión de ingenieros expertos

en el tema de gerencia de proyectos, se extrajo la información más relevante para el desarrollo

del documento y así poder realizar un proceso cuantitativo que permitiera identificar los aspec-

tos más relevantes considerados por ellos al momento de dirigir diferentes proyectos.

Fue de gran utilidad tener en cuenta el estándar de la ISO 17799, referente a la seguridad de la

información, debido a que el aspecto de la seguridad en un proyecto es algo que normalmente

no se tiene presente y no se contempla dentro de los estándares referentes a la gerencia de pro-

yectos.

Para el desarrollo de la guía fue importante tener en cuenta el punto de vista de un auditor de-

bido a que la guía propuesta se basa principalmente en una de las herramientas más utilizadas

en esta área, además el auditor aportó ideas relevantes gracias a la función de control que des-

empeña en su trabajo.


Página 78

En el proceso de validación de la guía se contó con diferentes perfiles de gerentes en proyectos

de sistemas de información, es decir personas que tuvieran especialización en gerencia, certi-

ficado en PMI o que solamente contaran con un conocimiento empírico, para obtener una re-

troalimentación más objetiva.

La realización de este trabajo aportó a la formación tanto profesional como académica de las

autoras, en cuanto al conocimiento del área de gerencia de proyectos y de auditoría, siendo útil

para ser aplicado en un futuro puesto de trabajo.


Página 79


12. TRABAJOS FUTUROS

Con base en el trabajo que se llevó a cabo, es mejorar esta propuesta desarrollando un software que

incluya los siguientes aspectos:

Cálculo automático de los resultados de las listas de chequeo de cada fase, mostrando cuál

es el estado hasta el momento de la gestión.

Generación de recordatorios sobre tareas pendientes y alertas programadas sobre fechas

límites, de acuerdo al cronograma establecido.

Generación de planes de mejora con base en las preguntas planteadas en cada lista de che-

queo y según las falencias que se hayan encontrado luego validar cada fase.

Base de conocimiento apoyándose en las lecciones aprendidas recopiladas como resultado

de la aplicación de la guía.

Banco de preguntas con la posibilidad de agregar preguntas y de que se genere cada lista

de chequeo según el tipo de proyecto.

Contar con una estructura de puntos de control, que permita efectuar nuevas adiciones de

otros que se consideren importantes realizar el seguimiento y control.


Página 80

13. REFERENCIAS

[1] Channel Planet Inc. 2005. Channel Planet. [En línea] 07 de Febrero de 2005. [Citado el: 22

de Febrero de 2008.] http://www.channelplanet.com/.

[2] Francisco Ruiz, M. P. (2000). Grupo Alarcos - Universidad De Castilla - La Mancha. Re-

cuperado el 26 de Mayo de 2008, de http://alarcos.inf-

cr.uclm.es/per/fruiz/cur/mso/trans/s10.pdf

[3] Gran Bretaña. Oficina del Comercio del Gobierno. (2005). Best practice for ICT infrastruc-

ture management. London.

[4] ILX Group plc. (2008). PRINCE2 Foundation & PRINCE2 Practitioner Project

Management Training. Recuperado el 20 de Marzo de 2008, de

http://www.prince2.com/what-is-prince2.asp.

[5] International Organization For Standardization. (s.f.). ISO/IEC 12207:2008. Recuperado el

25 de 04 de 2008, de

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=43

447

[6] ISO 27000.es. (s.f.). ISO 27000.es. Recuperado el 03 de Mayo de 2008, de

http://www.iso27000.es/iso27000.html

[7] IT Governance Ltd. (s.f.). IT Governance. Recuperado el 28 de 04 de 2008, de

http://www.itgovernance.co.uk/itilv3.aspx

[8] López Novella, M. Á., Sánchez de la Nieta, L. G., Parras Cobo, M. J., & Fernández

Fernández, R. M. (2005 -2006). Marco de evaluación EFOM – Basado en la norma interna-

cional ISO 12207.

[9] OGC Best Management Practice. (s.f.). OGC Best Management Practice - ITIL. Recupera-

do el 28 de 04 de 2008, de http://www.best-management-practice.com/Knowledge-

Centre/Best-Practice-Guidance/ITIL/?trackid=002205

[10] Porque fracasan los Gerentes de Proyectos En Colombia. PSL-Productora De Software

S.A. 2005. Bogotá: s.n., 2005.

[11] Project Management Institute. (2004). Guía de los Fundamentos de la Dirección de

Proyectos - Tercera Edición. Newtown Square, PA.


Página 81


[12] Project Management Institute, Inc. (2006). Project Management Institute - Santafe De

Bogotá Chapter. Recuperado el 30 de Mayo de 2008, de

http://www.pmicolombia.org/faq.htm#Beneficios %20individuales%20de%20la%20Certifi

cación.

[13] Sánchez, F. (6 de Marzo de 2008). MKM Publicaciones. Recuperado el 26 de Mayo de

2008, de http://www.mkm-pi.com/mkmpi.php?article1817

[14] Siegelaub, Jay M. «PRINCE2 Download Centre.» PRINCE2 Download Centre.

http://www.prince2.com/prince2-downloads.asp (último acceso: 20 de 07 de 2008).

[15] Software Engineering Institute. Software Engineering Institute-Carnegie Mellon. 2008.

http://www.sei.cmu.edu/cmmi/general/index.html (último acceso: 18 de Marzo de 2008).

[16] Tamayo, Mario Tamayo y. «ICFES.» ICFES. 1999.

http://200.26.128.174:8080/portalicfes/home_2/rec/arc_71.pdf (último acceso: 19 de Marzo

de 2008).

[17] V Encuesta de Gerencia de Proyectos. Vigil, Alberto Cueto. 2007. Bogotá : s.n., 2007.

[18] W3J.COM. (s.f.). W3J- Corporate Governance: News, plans & Documentation. Recupe-

rado el 27 de mayo de 2008, de http://www.w3j.com/5/s3.instone.html


Página 82

14. BIBLIOGRAFÍA

[1] Angarita, R. K. (2006). Estadística : conceptos y aplicaciones de los métodos de muestreo .

Cali : Editorial Universidad del Valle.

[2] APM Group Limited. (27 de Mayo de 2008). ITIL- IT Infrastructure Library. Recuperado el 27

de Mayo de 2008, de http://www.itil-

officialsite.com/Qualifications/ITILV3QualificationScheme.asp

[3] Estructuracion de las organizaciones de tecnologías de la información en torno a procesos y

servicios: COBIT, CMMI e ITIL. (Octubre, 2006). Comunicaciones de Telefonica I+D , 160.

[4] Francés, A. (2004). Estrategia y planes para la empresa : con el cuadro de mando integral.

México: Prentice Hall.

[5] Garcia, S., & Turner, R. (2007). CMMI® survival guide : just enough process improvement.

New Jersey .

[6] Gido, Jack. Administración exitosa de proyectos. International Thompson, 1999.

[7] Gran Bretaña. Oficina del Comercio del Gobierno. (2002). ICT infrastructure management .

London: ItSMF.

[8] IT Governance Institute . (2005). COBIT® 4.0 . Rolling Meadows, IL .

[9] IT Governance Institute. (2007). COBIT® Mapping: Mapping of ITIL® With. Rolling

Meadows, IL.

[10] IT Governance Institute . (2006). COBIT Mapping: Mapping of PMBOK With COBIT 4.0.

Rolling Meadows, IL.

[11] IT Governance Institute.. Mapping of ISO/IEC 17799:2000 With COBIT 4.0. Rolling

Meadows, IL, 2007.

[12] IT Governance. (s.f.). IT Governance. Recuperado el 29 de Abril de 2008, de

http://www.itgovernance.co.uk/pmbok.aspx

[13] Kaplan, R. S., & Norton, D. P. (2004). El cuadro de mando integral : the balanced scorecard .

Barcelona.


Página 83


[14] McConnell, Steve. Desarrollo y gestión de Proyectos Infomáticos. Madrid: McGraw-Hill,

1996.

[15] Nils-Göran Olve, J. R., & Ganzinelli, t. C. (2004). Implantando y gestionando el cuadro de

mando integral : guía práctica del balanced scorecard. Barcelona, España .

[16] Niven, P. R. (2000, 2004). El cuadro de mando integral paso a paso : maximizar la gestión y

mantener los resultados . Barcelona.

[17] Piattini, M. G. (2001). Auditoría informática : un enfoque práctico. Alfaomega.

[18] Pressman, R. (2005). Ingenieria Del Software-Un Enfoque Práctico. Mexico: McGraw Hill.

[19] Proexport Colombia 2005. (28 de Mayo de 2008). Proexport Colombia. Recuperado el 28 de

Mayo de 2008, de

http://www.proexport.gov.co/VBeContent/NewsDetail.asp?ID=5623&IDCompany=20

[20] Project Smart. (2007-2008). Project Smart. Recuperado el 29 de Abril de 2008, de

http://www.projectsmart.co.uk/pmbok.html

[21] PSL-Productora De Software S.A. (2005). Porque fracasan los Gerentes de Proyectos En

Colombia. Bogotá.

[22] Ross, S. M. (2007). Introducción a la estadística . Barcelona: Reverté.

[23] Sallenave, Jean Paul. Gerencia y planeación estrategica. Norma, 1985.

[24] Sommerville, I. (2002). Ingenieria de Software. Pearson Educación.

[25] Stair, R. (2001). Principios de sistemas de información : enfoque administrativo. Mexico:

International Thomson.

[26] Vigil, A. C. (2007). V Encuesta de Gerencia de Proyectos. Bogotá.

[27] W3J.COM. (s.f.). W3J- Corporate Governance: News, plans & Documentation. Recuperado el

27 de mayo de 2008, de http://www.w3j.com/5/s3.instone.html

[28] Weber, R. A. (1998). Information Systems Control and Audit. Pearson Education.

propuesta para trabajo de grado - …pegasus.javeriana.edu.co/~cis0810is10/memorias.pdf · cada uno...

Documents