Control de gestión de proyectos de software

Propuesta de un procedimiento para el Control de
Gestión de los Proyectos de Software
RESUMEN
El presente trabajo titulado: Propuesta de un Procedimiento para el Control de Gestión de los
Proyectos de Software, se realizó en la Facultad Tres de la Universidad de las Ciencias Informáticas
(UCI).
El análisis de los resultados a los diagnósticos realizados al Control de Gestión de Proyectos de
Software en la Facultad Tres, permitió definir el problema científico: ¿Cómo llevar a cabo el Control
de Gestión de los Proyectos de Software de la Facultad Tres de la UCI, para que los resultados de la
esfera productiva sean eficientes?
Para la solución al problema de investigación se realizó una entrevista estructurada, tomando como
población el total de planificadores de proyectos de la Facultad Tres de la UCI. Se analizaron los
resultados de la entrevista para determinar dentro del Proceso de Desarrollo de Software las áreas
claves sobre las cuales operar, sus variables e indicadores a medir en estas. Además se realizó una
entrevista no estructurada a los directivos de las Direcciones de Producción 2 y 4 de la
Infraestructura Productiva en la UCI para fundamentar los indicadores propuestos.
Luego del análisis e interpretación de los resultados de los métodos de investigación empleados, y
de la revisión de 40 documentos bibliográficos, entre ellos libros, referencias de páginas web,
documentos electrónicos relacionados con el tema de investigación, se realizó una propuesta de un
Procedimiento para el Control de Gestión de los Proyectos de Software, lo cuál permitió probar la
hipótesis de la investigación.
PALABRAS CLAVE: Diagnóstico, Gestión de Proyecto, Control de Gestión, Procedimiento.
Anisleydi Céspedes Vega
INDICE DE CONTENIDOS
RESUMEN................................................................................................................................................I
INTRODUCCIÓN....................................................................................................................................1
CAPÍTULO I: LA GESTIÓN DE PROYECTOS. PROCESO DE CONTROL DE GESTIÓN DE
PROYECTOS DE SOFTWARE. LA MEDICIÓN DE LA EJECUCIÓN DE LOS MISMOS................5
1.1 Génesis y Evolución de la Gestión de Proyectos............................................................................5
1.2 Gestión de Proyectos de Software..................................................................................................8
1.3 Control de Gestión........................................................................................................................12
1.4 Sistema de Control para la Gestión en Proyectos de Software.....................................................16
1.5 Medición del proceso de Control de la Gestión en Proyectos de Software. Definición de
Indicadores..........................................................................................................................................19
1.6 Conclusiones.................................................................................................................................24
CAPÍTULO II: ANÁLISIS DE LOS PASOS A DESARROLLAR PARA UN SISTEMA DE
CONTROL DE GESTIÓN DE LOS PROYECTOS DE SOFTWARE DE LA FACULTAD TRES DE
LA UCI...................................................................................................................................................26
............................................................................................................................................................26
2.1 Resultados del Control de la Gestión de los Proyectos de Software de la Facultad Tres de la
UCI.....................................................................................................................................................26
2.2 Análisis de la entrevista estructurada realizada al total de planificadores de Proyectos de la
Facultad Tres de la UCI......................................................................................................................27
2.3 Factibilidad de las herramientas existentes para la Gestión de Proyectos....................................36
2.3.1 Comparación entre las Herramientas.....................................................................................47
2.3.2 Herramienta Seleccionada.....................................................................................................48
2.4 Análisis de la entrevista no estructura aplicada a las Direcciones de Producción 2 y 4 de la
Infraestructura Productiva de la UCI..................................................................................................49
2.5 Conclusiones.................................................................................................................................51
CAPÍTULO III: PROPUESTA DEL PROCEDIMIENTO.....................................................................52
3.1 Elementos fundamentales para la ejecución del procedimiento. Operacionalización de las
variables del mismo............................................................................................................................52
3.2 Objetivo........................................................................................................................................54
3.3 Alcance.........................................................................................................................................54
3.4 Responsables.................................................................................................................................54
3.5 Desarrollo.....................................................................................................................................55
3.5.1 Identificación de los Indicadores para el Procedimiento.......................................................55
3.5.2 Esquema del Procedimiento Propuesto.................................................................................73
3.5.3 Descripción del Procedimiento..............................................................................................74
3.6 Conclusiones.................................................................................................................................77
CONCLUSIONES..................................................................................................................................78
RECOMENDACIONES.........................................................................................................................79
BIBLIOGRAFÍA REFERENCIADA.....................................................................................................80
BIBLIOGRAFÍA CONSULTADA.........................................................................................................82
ANEXOS................................................................................................................................................85
GLOSARIO...............................................................................................................................................I
..................................................................................................................................................................II
ÍNDICE DE TABLAS
TABLA 1. ASPECTOS ADICIONALES. NIVEL DE COINCIDENCIA POR PROYECTOS............32
TABLA 2. RESPUESTAS A LA PREGUNTA 10 DE LA ENTREVISTA............................................34
TABLA 3. RESPUESTAS A LA PREGUNTA 11 DE LA ENTREVISTA............................................34
TABLA 4. COMPARACIÓN ENTRE LAS HERRAMIENTAS. FUENTE: ELABORACIÓN PROPIA
................................................................................................................................................................48
TABLA 5. OPERACIONALIZACIÓN DE LAS VARIABLES DEL PROCEDIMIENTO. FUENTE:
ELABORACIÓN PROPIA....................................................................................................................54
TABLA 6. PORCENTAJE DE DEFECTOS POR TIPO. FUENTE: ELABORACIÓN PROPIA........62
TABLA 7. HORAS DE TRABAJO PLANIFICADAS POR INTEGRANTE. FUENTE:
ELABORACIÓN PROPIA....................................................................................................................87
TABLA 8. DOCUMENTAR INDICADORES. FUENTE: ELABORACIÓN PROPIA.......................88
ÍNDICE DE FIGURAS
FIG. 1 ESTRUCTURA DE PRODUCCIÓN DE LA FACULTAD TRES DE LA UCI...........................1
FIG. 4 NIVEL DE CONCORDANCIA CON LOS ASPECTOS DEL PARTE DE PRODUCCIÓN....28
FIG. 5 NIVEL DE CONCORDANCIA CON LOS ASPECTOS DEL 1 AL 4......................................29
FIG. 6 NIVEL DE CONCORDANCIA CON LOS ASPECTOS DEL 12 AL 17..................................30
FIG. 7 NIVEL DE CONCORDANCIA CON EL ASPECTO 19...........................................................30
FIG. 8 NIVEL DE CONCORDANCIA CON LOS ASPECTOS 30 Y 31.............................................31
FIG. 9 NIVEL DE CONCURRENCIA CON LOS ASPECTOS ADICIONALES................................32
FIG. 10 JERARQUÍA DE RESPONSABILIDAD EN LA EJECUCIÓN DEL PROCEDIMIENTO.
FUENTE: ELABORACIÓN PROPIA...................................................................................................55
FIG. 15 ESTRUCTURA DEL PROCEDIMIENTO PROPUESTO. FUENTE: ELABORACIÓN
PROPIA..................................................................................................................................................73
Introducción
Introducción
INTRODUCCIÓN
En la actualidad, con el continuo desarrollo de las tecnologías de información y las comunicaciones,
en las empresas se ha hecho cada vez más necesaria la dependencia de aplicaciones donde se
utilice el computador, por lo cual, la demanda de Software ha crecido de forma exponencial.
El Proceso de Desarrollo de un producto de Software es el marco de trabajo de las tareas que se
requieren para transformar los requisitos de un usuario en un sistema de Software, por tanto, un
proceso bien definido, apropiado para los productos que se van a construir y que satisfaga las
demandas del mercado, es un elemento crítico para cualquier organización.
La UCI1 como Universidad creada al calor de la batalla de ideas, tiene la misión de producir Software
y servicios informáticos a partir de la vinculación estudio - trabajo como modelo de formación. Su
producción se centra en el desarrollo de proyectos organizados en más de 30 polos productivos,
distribuidos entre 10 Facultades.
La Facultad Tres de la UCI está organizada en 3 polos productivos: Gestión de Recursos, Gestión de
Proyecto y Sistemas Legales, los cuales constituyen la unidad base para su producción de Software,
y es en este nivel donde se concibe la integración plena de producción, docencia e investigación.
Dichos polos, en el momento de la realización del presente trabajo, cuentan con 8 proyectos
productivos afines, con propósitos similares (figura 1).
Fig. 1 Estructura de Producción de la Facultad Tres de la UCI

Introducción
Introducción
A partir de un diagnóstico aplicado al Control de Gestión de Software a los proyectos que integran
los 3 polos productivos de la Facultad Tres de la UCI, se puede declarar la siguiente situación
problémica:
En la Facultad Tres actualmente no se ha logrado la integración de las funciones básicas de
dirección, en la evaluación de sus proyectos de producción de Software.
Existe poca experiencia en el desarrollo de la función básica de dirección (liderazgo) en la
Facultad Tres por parte de las personas que dirigen los proyectos, lo cual ejerce una
influencia negativa en aras de obtener el alcance de los mismos.
Las etapas de planificación y organización, así como el liderazgo, no están en función del
logro del Control de la Gestión de los proyectos.
Existe poco uso de los documentos de Gestión de Proyecto que deben ser llevados en los
mismos, así como poca utilización de herramientas de gestión utilizadas en función de la
misma.
De todo lo anteriormente expresado se puede concluir que no se tiene en cuenta a la Gestión de
Proyecto como categoría rectora de la ejecución de los proyectos, lo cual dificulta el control de este
proceso a nivel de Facultad.
La siguiente situación problémica permitió definir el Problema Científico: ¿Cómo llevar a cabo el
Control de Gestión de los Proyectos de Software de la Facultad Tres de la UCI, para que los
resultados de la esfera productiva sean eficientes?
Para la solución de este problema se plantea el siguiente Objetivo General: Proponer un
procedimiento para efectuar de forma eficiente el Control de Gestión en los Proyectos de Software
de la Facultad Tres de la UCI.
Se plantea como Objeto de Estudio: La Gestión de Proyectos.
Y el Campo de Acción se enmarca en: El Control de Gestión en Proyectos de Software de la
Facultad Tres de la UCI.
La Hipótesis de la investigación es: Si se logra desarrollar un procedimiento adecuado para el
Control de Gestión de los Proyectos de Software de la Facultad Tres de la UCI, se podría realizar el
mismo de forma eficiente.
Introducción
Introducción
Para desarrollar la presente investigación se llevaron a cabo un conjunto de Tareas:
Analizar el estado del arte del tema de investigación.
Analizar los resultados de los diagnósticos aplicados al Control de Gestión de los proyectos
que integran los polos productivos en la Facultad Tres de la UCI.
Interpretar el análisis de los diagnósticos para fundamentar la problemática de la
investigación.
Estudiar métodos que permiten desarrollar procesos de control, y valorar la utilización de los
mismos en proyectos de Software.
Estudiar y analizar herramientas factibles para la Gestión de Proyectos.
Proponer un procedimiento basado en los métodos y herramientas de estudio que responda
a la problemática de la investigación.
Redactar el informe final de la investigación.
Para la realización de las tareas mencionadas se emplearon los siguientes Métodos Científicos:
Métodos teóricos:
- Histórico - lógico: Este método permitió hacer todo un estudio y análisis de la bibliografía del
tema en cuestión, para poder determinar a través de la evaluación de la bibliografía
conceptos de la temática que permiten conocer el estado actual del fenómeno.
- Hipotético - deductivo: Este método jugó un papel fundamental en el proceso de verificación
de la hipótesis y permitió inferir conclusiones a partir del sistema de conocimientos que se
poseía.
- Analítico - sintético: Permitió hacer un análisis y estudio del objeto de la investigación y
además permitió arribar a conclusiones teóricas conceptuales.
Métodos empíricos:
Introducción
Introducción
- La observación: Permitió la observación en tiempo real producto de la participación en un
proyecto de Software por casi dos años en el rol de planificación y control.
- La revisión de documentos: Este método permitió la determinación del estado del arte del
objeto de estudio.
Métodos particulares:
- La entrevista: Permitió obtener y ampliar información sobre la situación problémica de la
investigación en el campo de acción.
Se realizó primeramente una entrevista de forma estructurada a los planificadores de todos
los proyectos de Software de la Facultad Tres de la UCI, la cual se basó en un cuestionario
fijo. También se aplicó una no estructurada a los directivos de las Direcciones de Producción
2 y 4 de la Infraestructura Productiva, con el objetivo de obtener criterios de una forma más
abierta y flexible.
Aporte práctico esperado del trabajo
La propuesta de un procedimiento que le permita a la dirección de producción de la Facultad Tres de
la UCI efectuar un Control de Gestión de sus Proyectos de forma eficiente.
Capítulo I
Capítulo I
CAPÍTULO I: LA GESTIÓN DE PROYECTOS. PROCESO DE CONTROL DE GESTIÓN DE
PROYECTOS DE SOFTWARE. LA MEDICIÓN DE LA EJECUCIÓN DE LOS MISMOS.
Introducción
Este capítulo se dedica a fundamentar teóricamente la problemática de la investigación, en el mismo
se harán análisis de los conceptos relacionados con el tema en cuestión, enfatizando en el término
Proyecto, la Gestión de Proyecto, la Gestión de Proyectos de Software y Control de Gestión
específicamente como parte de esta. Se hace un acercamiento a la implantación de un sistema de
Control de Gestión de Proyectos de Software, así como la importancia que tiene la medición en la
Gestión de Proyectos de Software.
1.1 Génesis y Evolución de la Gestión de Proyectos
La Gestión es el conjunto de diligencias que se realizan para desarrollar un proceso o para lograr un
producto determinado. La misma es entendida como una función institucional global e integradora de
todas las fuerzas que conforman una determinada organización o proyecto.
Desde épocas muy tempranas de la historia de la humanidad, la Gestión de Proyectos tuvo gran
importancia y repercusión. Es evidente que las técnicas de gestión no surgieron de manera
espontánea. Surgen de un proceso continuo que estaba permanentemente sujeto a los cambios
exigidos por la necesidad de un proceso directivo, administrativo, o de gestión para los proyectos de
aquel entonces.
En la construcción de las pirámides de Egipto y las del pueblo Maya se hizo uso de las técnicas de la
misma en su realización. Estas técnicas permitieron obtener la construcción de las pirámides, a
través de la colocación de millones de piedras en su exacto lugar; y que diez mil personas trabajasen
de la manera más eficaz y eficientemente posible en la realización de las mismas.
Los constructores de estas notables estructuras de pirámides fueron los primeros directores de
proyectos del mundo. A pesar de que no contaban con la ayuda de ordenadores, ni con herramientas
de programación, ni con papel para dibujar planos, dirigieron proyectos de una complejidad
excepcional utilizando las herramientas más sencillas posibles que tenían a su alcance.
Esta ciencia se ha venido desarrollando desde las últimas décadas del siglo pasado, y se basa en la
planificación del trabajo y en el posterior seguimiento y control de la ejecución del mismo.
Capítulo I
Capítulo I
La Gestión de Proyectos predictiva o clásica es una disciplina formal de gestión basada en la
planificación, ejecución y seguimiento a través de procesos sistemáticos, repetibles y escalables.
Esta asume que el proceso a gestionar, se desarrolla en un entorno estático y predecible en el cual
el objetivo de su esfuerzo es mantener cronograma, presupuesto y recursos.
La correcta Gestión de Proyectos requiere una panorámica actualizada, una planificación detallada y
la capacidad de realizar análisis de seguimientos basándose en datos objetivos. La misma está
encaminada a satisfacer o a colmar las necesidades y expectativas de una organización mediante un
proyecto.
Diferentes autores enuncian conceptos a cerca del término Proyecto:
Proyecto es el esfuerzo temporal llevado a cabo para crear un producto o servicio. Es una
secuencia de eventos con comienzo y final, dirigida a lograr un objetivo y realizada por
personas dentro de parámetros establecidos como los de tiempo, costo, recursos y calidad.
(Meneses, 2001)
Célula básica para la organización, ejecución, financiamiento y control de actividades
vinculadas con la investigación científica, el desarrollo tecnológico, la innovación tecnológica,
la prestación de servicios científicos y tecnológicos de alto nivel de especialización, las
producciones especializadas, la formación de recursos humanos, la gerencia y otras, que
materializan objetivos y resultados propios o de los programas en que están insertados y que
tienen a su disposición un grupo de recursos materiales y humanos para lograr en un tiempo
determinado los objetivos propuestos. (León, 2005)
Conjunto de actividades interrelacionadas que tienen un objetivo común, alcanzable
automáticamente como unidad de acción en un período de tiempo determinado, a los que
están asignados personas y medios materiales, informáticos y financieros. (Ciget, 2005)
Se puede definir un proyecto como un conjunto de actividades interdependientes orientadas
a un fin específico, con una duración predeterminada. Los objetivos deben ser concretos,
mesurables, alcanzables y retadores. (Soleiro, 2006)
Un proyecto consiste en colocar/utilizar los recursos para lograr un objetivo específico
siguiendo un esquema planificado y organizado. (Fernández, 2007)
Capítulo I
Capítulo I
En las definiciones antes expuestas por cada uno de los autores, se puede observar que las mismas
giran entorno a una idea. Los proyectos son una estructura compuesta por recursos humanos y
materiales, reunidos en una organización temporal, respondiendo a fines y objetivos específicos. En
la realización del presente trabajo este es el concepto que se va a utilizar para caracterizar lo que se
entiende por proyecto en la Gestión de Proyectos y en la Gestión de Proyectos de Software.
Existen ciertos matices comunes a muchos proyectos: ...bajo unos recursos limitados, con un
calendario y presupuesto que cumplir, y con el producto o servicio con la calidad convenida entre los
participantes del proyecto”.
Para ello es necesario realizar una Gestión del Proyecto que planifique, organice, dirija, y controle
los recursos de la compañía para un objetivo a corto plazo relativo que ha sido establecido para
cumplir metas y objetivos específicos”. (Kerzner, 1995)
El Instituto de Gestión de Proyectos (PMI, 2004) define la misma como “…la aplicación de
conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para satisfacer
los requerimientos del mismo”.
Plantea además que esta ciencia, se ejecuta a través del uso de procesos como: inicio, planificación,
ejecución, control y cierre (figura 2).
Fig. 2 Grupos de procesos de la Gestión de Proyectos. (PMI, 2004)
El equipo del proyecto maneja el trabajo del proyecto el cual involucra:
Demandas contrapuestas sobre: alcance, tiempo, costo, riesgos y calidad.
Capítulo I
Capítulo I
Interesados con diferentes necesidades y expectativas.
Requerimientos identificados.
Es importante notar que muchos de los procesos de la Gestión de Proyectos son iterativos por
naturaleza. Esto es debido, en parte, a la existencia y necesidad de elaboración progresiva dentro
del proyecto, a través del ciclo de vida del mismo. Es decir, cuanto más se conozca en profundidad
un proyecto, mejor preparado se está para manejarlo con un mayor nivel de detalle.
El primer paso para llegar a comprender la Gestión de Proyecto es definir lo que es un proyecto, el
tipo de proyecto que se va a realizar y tener bien claro cuáles son sus características. Una vez
reunidos estos elementos, la realización de la gestión sobre ellos será más eficiente. La eficiencia y
eficacia del proceso aumenta en la medida que se incremente su integración a la estrategia general
de la organización.
Los procesos de gestión comienzan con una planificación previa, la cual se realiza sobre un análisis
detallado del trabajo que se quiere realizar y su descomposición en tareas. Estas comienzan por un
conjunto de requisitos de un proyecto o una obra determinada que tiene inicio y fin con objetivos
específicos. Los requisitos deben detallar lo que se quiere hacer, y bajo estas condiciones se
desarrolla un plan adecuado a los recursos y tiempos disponibles. Durante la construcción se sigue
de cerca la ejecución para detectar posibles desviaciones y tomar medidas para corregirlas.
Este proceso se identifica como la gestión predictiva, que predice a través de un plan inicial las
características del desarrollo de un trabajo en: tiempos, recursos, costes y secuencia de
operaciones. Su principal objetivo es conseguir que el desarrollo se lleve a cabo según lo “previsto”;
y basa el éxito del proyecto en el cumplimiento de todo lo programado.
1.2 Gestión de Proyectos de Software
Con el desarrollo de la informática y las comunicaciones, los proyectos de Software nacen como una
respuesta a la necesidad de crear cada día determinados productos para la evolución del mundo de
la informática.
Estos cumplen determinados objetivos, están enmarcados dentro de una empresa de Software que
tiene una finalidad con clientes específicos. Por tanto, tendrán siempre objetivos y finalidades
específicas. Estas características son consideradas como las metas para el logro de los mismos. Y
Capítulo I
Capítulo I
se logran con la aplicación de la gestión integrada o administración de todos los procesos que se
realizan a lo largo de su ciclo de vida.
La construcción de proyectos de Software es una tarea relativamente compleja, en la que participan
equipos multidisciplinarios en un período de tiempo extenso, razón fundamental por la que necesitan
ser gestionados. Ya que los recursos e inversiones utilizados en la realización de los mismos se
deben optimizar para obtener los objetivos en función de ellos.
Un proceso de Software se concreta en un pequeño número de actividades del marco de trabajo que
son aplicables a todos los proyectos de Software, independientemente de su tamaño o complejidad.
Estas actividades son un número de conjuntos de tareas, siendo cada conjunto una colección de
tareas de trabajo de ingeniería del Software, hitos de proyecto, productos de trabajo, y puntos de
garantía de la calidad. Estos conjuntos permiten que las actividades del marco de trabajo se adapten
a las características del proyecto de Software en cuestión y a los requisitos del equipo de dicho
proyecto (figura 3).
Fig. 3 El proceso de Software. (Pressman, 2000)
Los modelos de proceso de Software, los métodos de ingeniería y las herramientas de
automatización del mismo, se adaptan con éxito a la amplia gama de aplicaciones de la industria.
Los gestores de proyectos y profesionales informáticos, reconocen la necesidad de trabajar con un
enfoque más disciplinario del Software, y la importancia que tiene una buena Gestión de Proyecto
que guíe los métodos de ingeniería, para lograr un producto que satisfaga las necesidades del
cliente de forma eficiente.
Capítulo I
Capítulo I
La Gestión de Proyectos de Software tiene como finalidad principal la planificación, el seguimiento y
control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de
un sistema informático. (CSI, 1999)
En la realización de un Software, todos gestionamos de algún modo. En el desarrollo del mismo, el
ámbito de la gestión de las actividades varía en función de la persona que las realiza. Y existen gran
variedad de técnicas y herramientas en función del control de las mismas. El equipo de trabajo debe
centrar sus actividades en afán de responder al cliente y a la calidad del producto.
Los ingenieros de Software y sus gestores adaptan el proceso a sus necesidades y lo siguen, de
esta forma proporcionan estabilidad, control y organización a las actividades, obteniendo programas,
documentos, y datos que se producen como resultado de las actividades de ingeniería definidas por
el proceso.
Las áreas claves del proceso forman la base del Control de la Gestión del Proyecto de Software,
según Pressman (Pressman, 2000). Estas establecen el contexto en el que se aplican los métodos
técnicos, se obtienen productos del trabajo que pueden ser modelos, documentos, datos, informes,
formularios, etcétera. Se establecen hitos, se asegura la calidad, y el cambio se gestiona
adecuadamente.
Un proceso de Software define el enfoque que se toma cuando el Software es tratado por la
ingeniería, pero la ingeniería también comprende las tecnologías que tiene el proceso, métodos
técnicos y herramientas automatizadas.
La Gestión de Proyectos es una de las áreas claves dentro del Proceso de Desarrollo de sistemas
de Software, el cual implica la planificación, supervisión y control del personal, del proceso y de los
eventos que ocurren mientras evoluciona el Software desde la fase preliminar a la implementación
operacional. (Pressman, 2000)
También en otras ocasiones la enfocan como el arte de balancear objetivos en competencia,
gestionar los riesgos, y sobreponerse a las restricciones para crear con éxito un producto que
satisfaga las necesidades tanto de los clientes como de los usuarios finales.
Se puede definir que, cuando se habla de Gestión de Proyectos de Software, se trata de articular el
método para alcanzar un objetivo único y no repetitivo en un plazo, con principio y fin claros,
mediante las técnicas que nos proporciona la gestión como tal.
Capítulo I
Capítulo I
Esta ciencia indica, la planificación, supervisión del personal, del proceso y los eventos que ocurren
mientras evoluciona el Software hasta su fin.
El factor clave de la Gestión de Proyectos de Software es las actividades, las mismas se realizan en
dependencia de la jerarquía de ejecución que establezca el equipo de proyecto, en correspondencia
con la prioridad de cada una ellas.
El proceso de gestión de actividades es de gran importancia, ya que el número considerable de
personas que participan en los proyectos es muy variado, lo cual conlleva a que un proyecto de
Software, no sea más que un conjunto de actividades multidisciplinarias, en las cuales se necesita
llevar un control de las tareas que constituyen y forman el Proceso de Desarrollo de Software.
Para que la Gestión de Proyecto de Software sea eficaz, esta debe estar enfocada al personal,
producto, proceso y proyecto (Pressman, 2000). El gestor de proyecto debe considerar el esfuerzo
humano y la comunicación con el cliente en el proceso de negocio, como uno de los aspectos más
importantes.
El personal debe se estar organizado para desarrollar el trabajo del Software con efectividad. La
comunicación con el cliente debe ocurrir de forma efectiva para que se comprendan el alcance del
producto y los requisitos. Debe seleccionarse el proceso adecuado para el personal y el producto.
El proyecto debe planificarse estimando el esfuerzo y el tiempo para cumplir las tareas, definiendo
los productos del trabajo, estableciendo puntos de control de calidad y los mecanismos para
controlar y supervisar el trabajo definido en la planificación. La gestión de la complejidad de los
proyectos de Software se logra a través de la planificación y control de los mismos.
El número de proyectos que fracasan hoy en día es a causa de un desbordamiento de planificación y
costo, o proyectos mal concebidos desde el primer momento. Esto provoca que los clientes pierdan
el interés en la ejecución de los mismos y sean cancelados.
La creación de un equipo de proyecto unido y motivado será la clave para el logro definitivo de las
metas y por consiguiente, la creación del equipo es una habilidad esencial en la administración de
proyectos. (Gido, 1999)
Capítulo I
Capítulo I
1.3 Control de Gestión
En la propia evolución de las organizaciones y su desempeño como sistemas abiertos a un entorno
cada vez más competente, el control ha reforzado una serie de etapas que lo caracterizan y en el
cual las organizaciones deben definir la información y hacerla fluir e interpretarla acorde con sus
necesidades, para tomar decisiones que le permitan enfrentar y mantenerse ante una feroz
competencia o en busca de la excelencia.
El control es una etapa primordial en la gestión, pues aunque una determinada organización cuente
con magníficos planes, una estructura organizacional adecuada y una dirección eficiente, el ejecutivo
no podrá verificar cuál es la situación real de la organización, si no existe un mecanismo que se
cerciore e informe si los hechos van de acuerdo con los objetivos.
El concepto de control es muy general y puede ser utilizado en cualquier contexto organizacional
para evaluar el desempeño general frente a un plan estratégico.
Varios son los estudiosos del tema que han escrito planteamientos acerca de este término:
El control consiste en verificar si todo ocurre de conformidad con el plan adoptado, con las
instrucciones emitidas y con los principios establecidos. Tiene como fin señalar las
debilidades y errores a fin de rectificarlos e impedir que se produzcan nuevamente. (Farol,
1961)
El proceso de medir los actuales resultados en relación con los planes, diagnosticando la
razón de las desviaciones y tomando las medidas correctivas necesarias. (Buchele, 1976)
El proceso para determinar lo que se está llevando a cabo, valorización y, si es necesario,
aplicando medidas correctivas, de manera que la ejecución se desarrolle de acuerdo con lo
planeado. (Terry, 1993)
La medición y corrección de las realizaciones de los subordinados con el fin de asegurar que
tanto los objetivos de la empresa como los planes para alcanzarlos se cumplan económica y
eficazmente. (Robert, 1994)
El control es una función administrativa: es la fase del proceso administrativo que mide y
evalúa el desempeño y toma la acción correctiva cuando se necesita. De este modo, el
control es un proceso esencialmente regulador. (Chiavenatto, 2000)
Capítulo I
Capítulo I
Como se puede apreciar la palabra control tiene muchas connotaciones y su significado depende de
la función o del área en que se aplique.
Este proceso puede ser entendido como: (Abad, 1997)
La función administrativa que hace parte del proceso administrativo junto con la planeación,
organización, liderazgo y lo que la precede.
Los medios de regulación utilizados por un individuo u organización, como determinadas
tareas reguladoras que un controlador aplica en una entidad para acompañar y avalar su
desempeño y orientar las decisiones.
La función restrictiva de un sistema para mantener a los participantes dentro de los patrones
deseados y evitar cualquier desvío.
Evidentemente todas esas definiciones representan concepciones incompletas del control, quizás
definidas en un modo subjetivo a falta de un contexto para su organización. La definición de dicho
término para el presente trabajo es la siguiente:
El control es una función administrativa, ya que forma parte del proceso de administración, que
permite verificar, constatar, medir, si la actividad, proceso, unidad, elemento o sistema seleccionado
está cumpliendo y alcanzando o no los resultados que se esperan.
Después de haber abordado los elementos claves que determinan el término control, podemos decir
que el mismo requiere de un entorno amplio de elementos básicos que intervienen en el proceso
que se gestiona para su ejecución.
Es por un lado parte de un objetivo definido dentro de parámetros de alcance para obtener logros, y
por el otro, exigecnicas específicas para llevarlo a cabo de manera efectiva dentro de un contexto
organizacional concreto. Como parte de un objetivo es determinante dentro del marco de la
planificación, y como parte de las exigencias para llevarlo a cabo no es más, que la sistematización
operativa del mismo.
El control aplicado a la gestión, implica obtener los factores que influyen en su ámbito
administrativo, distintos autores han definido el concepto de acuerdo a sus propias posiciones e
interpretaciones:
Capítulo I
Capítulo I
“Control de Gestión es un proceso mediante el cual los directivos aseguran la obtención de recursos
y su utilización eficaz y eficiente en el cumplimiento de los objetivos de la organización.”
(Menguzzato y Renau, 1986)
“La gestión es una mezcla de decisiones locales con objetivos globales de la compañía… el control
es una parte del sistema de información que responde a una de las preguntas gerenciales más
candentes: ¿cómo medir objetiva y constructivamente el desempeño local pasado? (Goldratt, 1992)
"... es el conjunto de mecanismos que puede utilizar la dirección que permiten aumentar la
probabilidad de que el comportamiento de las personas que forman parte de la organización sea
coherente con los objetivos de esta." (Amat, 1992)
es un instrumento de la gestión que aporta una ayuda a la decisión y sus útiles de dirección
van a permitir a los directores alcanzar los objetivos… es una función descentralizada y coordinada
para la planificación de objetivos, acompañada de un plan de acción y la verificación de que los
objetivos han sido alcanzados.“ (Jordán, 1995)
“El Control de Gestión consiste en un conjunto de procedimientos y cnicas, especialmente
cuantitativas, que ayudan a una gestión planificada y ordenada, mejorando así su eficiencia en el
logro de los objetivos estratégicos” (Bermejo, 1996)
De acuerdo con lo expresado por cada uno de los autores, se comprueba que la definición de
Control de Gestión no es única, varía con cada autor y con el transcurso de los años. Estos
coinciden en que el Control de Gestión es un sistema dinámico e importante para el logro de metas
organizacionales.
Al valorar los diferentes conceptos, se puede observar que a pesar de las diferencias entre los años
de publicación, casi la totalidad de los autores señalan a los objetivos como la categoría rectora,
porque el proceso de toma de decisiones está orientado a alcanzar los objetivos marcados y luego
estos son el patrón para evaluar a la gestión.
El Control de Gestión se relaciona con las siguientes actividades: formulación de objetivos, fijación
de estándares, utilización de recursos, medición de resultados, comparación de la realidad con la
norma, análisis de desviaciones, corrección del desempeño o mejora, comportamiento individual e
interpersonal.
Capítulo I
Capítulo I
Algunos consideran que el Control de Gestión comprende tanto la etapa de previsión como la
etapa de control. Otros lo ven más cercano a la ejecución y verificación, para otros abarca los
procesos de asignación de recursos, el seguimiento de las acciones y la evaluación del resultado.
La gestión comprende todos los procesos descritos anteriormente, puesto que constituyen la vía
para concretar y alcanzar la política general de una organización, y por ende, incluye al Control de
Gestión como su herramienta para evaluar si las decisiones que se toman al asignar y utilizar los
recursos, se alejan o se acercan a los objetivos.
Como conclusión podemos señalar que el Control de Gestión (CG) sirve para guiar la gestión hacia
los objetivos de la organización y es al mismo tiempo un instrumento para evaluarla. Por tanto, se
pueden declarar las siguientes características:
El CG es un medio para desplegar la estrategia en toda la organización.
El CG desarrolla actividades de planificación, control y diagnóstico, para que las reglas de
gestión locales se correspondan con la estrategia trazada por la organización, con un fin
económico: la elevación del nivel de desempeño global, asumiendo de este modo una
perspectiva integral de la organización.
El CG sirve para evaluar el desempeño de la organización, entendida como la medición y
análisis de los resultados, desde múltiples ángulos o criterios, para decidir qué acción tomar a
partir de los recursos disponibles, con una orientación hacia su mejora permanente en todos
los niveles de la organización.
El CG es un medio para movilizar el talento y la energía del colectivo hacia el logro de los
objetivos de la organización.
El CG es un medio para gestionar el cambio.
Estas características permiten valorar el proceso a través de dos concepciones comunes aceptadas
en el ámbito administrativo, por un lado se tiene al control como necesidad inherente al proceso de
dirección y por el otro, en un paradigma más integral vinculado no solo a la dirección formal, sino a
factores claves como la cultura, el entorno, la estrategia, lo psicológico, lo social y la calidad.
Capítulo I
Capítulo I
1.4 Sistema de Control para la Gestión en Proyectos de Software
El desarrollo de un proyecto siempre estará acompañado por un nivel de incertidumbre que
dependerá de las distintas opciones que existan para su ejecución, por lo que debe ser planificado y
controlado de tal forma, que todas las posibilidades de acción establecidas puedan ser analizadas y
discutidas para alcanzar los objetivos propuestos. (León, 2005)
El plan elaborado para la ejecución de un proyecto se puede alterar por una planificación deficiente,
no disponer de los recursos previstos en la fecha planificada, presentarse situaciones imprevistas y
hacer modificaciones por propia voluntad.
Esto justifica la necesidad del control para evitar o reducir al mínimo las desviaciones en costes y
plazos o al menos detectarlas cuanto antes, vigilar todas las actividades de desarrollo del sistema,
así como facilitar la toma de decisiones correctas y evitar contradicciones en la utilización de los
recursos disponibles.
Para poder ejercer un correcto control del proyecto es necesario que por un lado el gerente dedique
todo el tiempo que sea preciso para vigilar el estado de cada una de las tareas que se están
desarrollando, debe tener claros los objetivos que persigue el proyecto, bien definido los criterios de
éxito y fracaso, dominio de los recursos necesarios y los que realmente son asignados, costo total
del proyecto y su estado de ejecución, conocer los puntos críticos y de decisión, las prioridades
establecidas y la fecha de terminación.
Por otro los ejecutores deben asumir la parte que les corresponde. Se debe contar con especialistas
expertos en planificación, prestando especial interés a aquellas tareas que están sufriendo algún
retraso. En el momento en que se detecte cualquier desviación hay que analizar las causas para
poder efectuar las correcciones oportunas y recuperar el tiempo perdido.
Para desarrollar un sistema de Control de Gestión de Proyectos hay que tener la estructura del
sistema que se intenta monitorear de manera global. A partir de ahí se obtiene lo que está ocurriendo
en la organización. No se trata de conocer detalladamente la organización, sino que se pretende
actuar por excepción en aquellas situaciones que ameriten entrar en detalle.
Los pasos para desarrollar el sistema son los siguientes: (Abad, 1997)
1- Diagnóstico institucional: Todo proceso de Control de Gestión comienza con el estudio propio
del sistema a controlar. El diagnóstico tiene como objetivos, identificar posibles obstáculos que
Capítulo I
Capítulo I
puedan interferir en la eficacia del sistema, del mismo modo establecer si están dadas las
condiciones para la ejecución del sistema propuesto e identificar los procesos claves para que el
sistema opere sobre ellos y sus variables, a fin de garantizar en lo posible el éxito organizacional.
Generalmente los análisis institucionales se orientan hacia el estudio estratégico de la organización,
es decir, identificando fortalezas y debilidades internas con su relación al entorno amenazante o
facilitador de resultados productivos, de igual manera analiza normas, sistemas financieros, cultura
organizacional, estructura, capacidad estratégica, desempeño institucional de RRHH, entre otros.
2- Identificación de procesos claves: Luego de conocer como se encuentra el sistema a controlar,
es necesario identificar los procesos claves para el éxito de la organización, el Control de Gestión no
actúa sobre todos los procesos internos de la misma, sino por el contrario se centra en aquellos
suficientemente importantes en el desempeño eficaz del sistema a controlar. Dentro de los procesos
identificados se seleccionan determinados subprocesos o áreas claves, las cuales son consideradas
como las que más influyen en el correcto desarrollo de dichos procesos identificados.
3- Diseño del sistema de indicadores: De la identificación de las áreas claves, se originan los
indicadores que van a permitir medir atributos de dichos procesos y tomar las decisiones pertinentes
para su corrección. Un indicador se define como la relación entre variables cuantitativas o
cualitativas que permiten observar la situación y las tendencias de cambio generadas en el objeto o
fenómeno observado, respecto a los objetivos y metas previstas e influencias esperadas.
En la ejecución de estos pasos influyen determinados factores que le permiten al sistema definir de
manera objetiva el espacio o marco donde se va a trazar el mismo:
El entorno: este puede ser estable o dinámico, variante cíclicamente o completamente
atípico. Una buena adaptación del entorno facilita el desarrollo en la entidad.
Los objetivos: ya sean de rentabilidad, de crecimiento, sociales, ambientales, entre otros.
La estructura: según sea, funcional o divisional, implica establecer variables distintas, y por
ende objetivos y sistemas de control también distintos.
El tamaño: esta condición está relacionada con la centralización, mientras más grande sea la
entidad es necesario descentralizarla, porque afecta la toma de decisiones debido a la gran
cantidad de información que se maneja.
Capítulo I
Capítulo I
La cultura: las relaciones humanas son muy importantes, y se debe incentivar y motivar al
personal que labora en la entidad.
Una vez realizado el sistema de Control de Gestión teniendo en cuenta todos estos elementos, se
podrán verificar el avance y desarrollo del proyecto en todos sus aspectos; establecer el grado de
cumplimiento de los objetivos; crear a partir de los objetivos los procedimientos a seguir, los recursos
a implementar, la información básica a recoger y verificar la misma.
Los sistemas de control de proyectos tienen cuatro elementos básicos: entradas, procesos, salidas y
realimentación. Los mismos deben cumplir los siguientes requerimientos de diseño: (Lourdes, 2000)
Un marco común de integración del alcance, del plazo, del costo, del tiempo y de la calidad.
Capacidad para seguir el progreso de los parámetros verdaderamente significativos para el
proyecto.
Respuesta rápida.
Capacidad de predicción del valor final.
Datos apropiados y exactos para la toma de decisiones a cada nivel de dirección.
Capacidad para el análisis de problemas.
Informes de excepción.
Evaluación cuantitativa inmediata de soluciones alternativas (análisis “que pasaría si…”).
Una vez implantado un sistema de control en un proyecto de Software para que sea efectivo es
necesario que exista:
Definición clara y exacta de las actividades a desarrollar.
Planificación completa de todo el proyecto.
Buenas estimaciones de plazo, costo y rendimientos.
Comunicación clara del alcance de cada una de las tareas a realizar.
Medición puntual del progreso físico y del avance en costo.
Capítulo I
Capítulo I
Seguimiento continuo y periódico ante las incidencias, de la estimación del tiempo y costo
para completar el trabajo restante.
Comparación periódica del progreso físico y del avance en costos reales con lo
programado/presupuestado para ver las desviaciones y poder hacer proyecciones.
1.5 Medición del proceso de Control de la Gestión en Proyectos de Software. Definición de
Indicadores.
Las mediciones son cruciales en el progreso de todas las ciencias. El progreso científico se logra a
través de observaciones, generalizaciones basadas en datos y mediciones, y la derivación de teorías
se obtiene como resultado de estas (Stephen, 2000). Sin la verificación a través de los datos y las
mediciones, las teorías y las proposiciones permanecerían en un nivel abstracto y el
desconocimiento sobre el avance de las mismas sería cada vez peor.
La medición, dentro del contexto del control, está estrechamente vinculada con la planeación y el
establecimiento de objetivos. Como un sistema de control debe medir decisiones correctas, es
importante que los objetivos establecidos en el proceso de planeación sean relevantes para el
propósito de la organización. También se requiere que los controles sean suficientemente sencillos
para que puedan comprenderse; puedan mostrar de una manera oportuna desviaciones en relación
con los estándares2; y para que puedan iniciarse acciones correctivas antes de que se conviertan en
grandes problemas.
La medición tiene los siguientes fines: (Horna, 2004)
Informar: Transmitir y comunicar la información necesaria para la toma de decisiones.
Coordinar: Encaminar todas las actividades eficazmente a la consecución de los objetivos.
Evaluar: La consecución de las metas (objetivos) se logra gracias a las personas, y su
valoración es la que pone de manifiesto la satisfacción del logro.
Motivar: El impulso y la ayuda a todo responsable es de vital importancia para la
consecución de los objetivos.
 !
"#$%$
"
Capítulo I
Capítulo I
Se puede decir que la medición es la herramienta básica del control, el cual sirve de guía para
alcanzar eficazmente los objetivos planteados con el mejor uso de los recursos disponibles (técnicos,
humanos, financieros, etcétera.).
Todas las actividades pueden medirse con parámetros que enfocados a la toma de decisiones son
señales para monitorear la gestión. De esta forma se asegura que las actividades vayan en el
sentido correcto y permiten evaluar los resultados de una gestión frente a sus objetivos, metas y
responsabilidades. Estas señales son conocidas como indicadores de gestión.
Un indicador de gestión es la expresión cuantitativa del comportamiento y desempeño de un
proceso, cuya magnitud, al ser comparada con algún nivel de referencia, puede estar señalando una
desviación sobre la cual se toman acciones correctivas o preventivas según el caso. (Jaramillo,
2008)
Los indicadores surgen ante la necesidad de tener entidades más eficientes. Estos deben facilitar un
mejor control de todos los procesos en la organización, permitiendo medir, conocer y analizar los
resultados de esta labor. Los mismos se convierten en el mecanismo más eficaz y menos costoso
para saber hacia donde va la organización.
Los indicadores son necesarios para poder mejorar el desempeño. Pues, lo que no se mide no se
puede controlar, y lo que no se controla no se puede gestionar; por lo tanto, los mismos son
fundamentales para: (Nogueira, 2002)
Poder interpretar lo que está ocurriendo.
Tomar medidas cuando las variables se salen de los límites establecidos.
Definir la necesidad de introducir un cambio y poder evaluar sus consecuencias.
Planificar actividades para dar respuesta a nuevas necesidades.
El equipo de proyecto debe definir los indicadores que dan respuesta a las preguntas siguientes:
¿Qué se debe medir?
¿Dónde es conveniente medir?
¿Cuándo hay que medir?, ¿en qué momento o con qué frecuencia?
Capítulo I
Capítulo I
¿Quién debe medir?
¿Cómo se debe medir?
¿Cómo se van a difundir los resultados?
¿Quién y con qué frecuencia va a revisar o auditar el sistema de obtención de datos?
Para seleccionar los indicadores hay que tener en cuenta varios criterios. Uno de los más
significativos es el número de indicadores por áreas a controlar, este no debe ser grande. No es
necesario tener bajo control continuo muchos de ellos, sino solo los más importantes. La razón es
que demasiados indicadores difuminan el mensaje que quiere que se llegue, como resultado, los
esfuerzos se dispersan intentando perseguir demasiados objetivos al mismo tiempo. Se recomienda
empezar con una lista extensa de indicadores, y después es necesario un proceso de síntesis para
disponer de toda su fuerza una vez implementados.
Empleándolos en forma oportuna y actualizada, los indicadores permiten tener control adecuado
sobre una situación dada. La principal razón de su importancia radica en que es posible predecir y
actuar con base en las tendencias positivas o negativas observadas en su desempeño global.
Los indicadores son una forma clave de retroalimentar un proceso, de monitorear el avance o la
ejecución de un proyecto y de los planes estratégicos, entre otros. Y son más importantes todavía si
su tiempo de respuesta es inmediato, o muy corto, ya que de esta manera las acciones correctivas
son realizadas sin demora y en forma oportuna.
Para trabajar con los indicadores debe establecerse todo un sistema que vaya desde la correcta
comprensión del hecho o de las características, hasta la de toma de decisiones acertadas para
mantener, mejorar e innovar el proceso del cual dan cuenta.
La cantidad de indicadores que queden definidos para medir el funcionamiento de un proceso, es
mayor o menor en dependencia de la necesidad de funcionamiento que se quiera medir. Esto varía
de acuerdo a varios aspectos: condiciones del entorno, fase en la que se encuentra el proceso, ciclo
de vida del mismo, utilidad de sus resultados en el momento de ejecución del proceso, etcétera.
Para la construcción de indicadores de gestión son considerados los siguientes elementos:
(Jaramillo, 2008)
La Definición
Capítulo I
Capítulo I
Expresión que cuantifica el estado de la característica o hecho que quiere ser controlado.
El Objetivo
El objetivo es lo que persigue el indicador seleccionado. Indica el mejoramiento que se busca y el
sentido de esa mejora (maximizar, minimizar, eliminar, etcétera.).
El objetivo en consecuencia, permite seleccionar y combinar acciones preventivas y correctivas en
una sola dirección.
Los Valores de Referencia
El acto de medir es realizado a través de la comparación y esta no es posible si no se cuenta con un
nivel de referencia para comparar el valor de un indicador.
Existen los siguientes valores de referencia:
- Valor histórico:
Muestra como ha sido la tendencia a través del transcurso del tiempo. Permite proyectar y
calcular valores esperados para el período. Señala la variación de resultados, su capacidad real,
actual y probada, informa si el proceso está o ha estado controlado. Además dice lo que se ha
hecho, pero no dice el potencial alcanzable.
- Valor estándar:
El estándar señala el potencial de un sistema determinado.
- Valor teórico:
También llamado de diseño, usado fundamentalmente como referencia de indicadores
vinculados a capacidades de máquinas y equipos en cuanto a producción, consumo de
materiales y fallas esperadas. El valor teórico de referencia es expresado muchas veces por el
fabricante del equipo.
- Valor de requerimiento de los usuarios:
Representa el valor de acuerdo con los componentes de atención al cliente que se propone
cumplir en un tiempo determinado.
Capítulo I
Capítulo I
- Valor de la competencia:
Son los valores de referencia provenientes de la competencia; es necesario tener claridad que la
comparación con la competencia solo señala hacia dónde y con qué rapidez debe mejorar, pero
a veces no dice nada del esfuerzo a realizar.
- Valor por política corporativa:
A través de la consideración de los dos niveles anteriores se fija una política a seguir respecto a
la competencia y al usuario. No hay una única forma de estimarlos, se evalúan posibilidades y
riesgos, fortalezas y debilidades, y se establecen.
- Determinación de valores por consenso:
Cuando no se cuenta con sistemas de información que muestren los valores históricos de un
indicador, ni cuente con estudios para obtener valores estándar, para lograr determinar los
requerimientos del usuario o estudios sobre la competencia, una forma rápida de obtener niveles
de referencia es acudiendo a las experiencias acumuladas del grupo involucrado en las tareas
propias del proceso.
La Responsabilidad
Clarifica el modo de actuar frente a la información que suministra el indicador y su posible desviación
respecto a las referencias escogidas.
Los Puntos de Medición
Define la forma cómo se obtienen y conforman los datos, los sitios y momentos donde deben
hacerse las mediciones, los medios con los cuales hacer las medidas, quiénes hacen las lecturas y
cuál es el procedimiento de obtención de las muestras. Ello permite establecer con claridad la
manera de obtener precisión, oportunidad y confiabilidad en las medidas.
La Periodicidad
Define el período de realización de la medida, cómo presentan los datos, cuándo realizan las
lecturas puntuales y los promedios.
Capítulo I
Capítulo I
El Sistema de Procesamiento y Toma de Decisiones
El sistema de información debe garantizar que los datos obtenidos de la recopilación de históricos o
lecturas, sean presentados adecuadamente al momento de la toma de decisiones. Un reporte para
tomar decisiones debe contener no solo el valor actual del indicador, si no también el nivel de
referencia.
1.6 Conclusiones
Una vez concluido el presente capítulo se pueden declarar las siguientes conclusiones:
Los fundamentos teóricos de la Gestión de Proyectos permiten darle soporte a teoría de la
Gestión de Proyectos de Software, así como también le aporta los elementos básicos de la
misma, por lo que podemos plantear que la Gestión de Proyectos de Software constituye una
rama de la misma.
La Gestión de Proyecto permite el manejo de las variables que podrán darse en el transcurso
de la vida útil del proyecto o en su reformulación; la Gestión de Proyectos de Software
constituye una actividad protectora para el análisis de la concepción de cualquier proyecto,
con el fin de desarrollar el proceso de manera exitosa.
El Control de Gestión no debe verse ni diseñarse como un sistema aislado del trabajo
habitual en una organización; debe considerar los elementos específicos y permanentes que
intervienen en la dirección de una organización, de forma tal que coopere con el logro de sus
objetivos fundamentales.
El control tiene muchas connotaciones y su significado depende de la función o del área en
que se aplique. El mismo es de gran importancia debido a que:
- Establece medidas para corregir las actividades de forma que se alcancen los planes
exitosamente.
- Determina y analiza las causas que pueden originar desviaciones para que no
vuelvan a presentarse en un futuro.
Capítulo I
Capítulo I
- Proporciona información acerca de la situación de la ejecución de los planes.
- Permite la reducción de costos y ahorra tiempo al evitar errores, y su aplicación incide
directamente en el logro de la productividad de todos los recursos de la organización.
Los indicadores de gestión son considerados como los signos vitales de la organización, ya
que a través de su continuo monitoreo, proporcionan información confiable, significativa y
oportuna, la cual va a ayudar a saber en qué situación se encuentra la entidad y de esta
manera posibilitar la toma de decisiones.
Capítulo II
Capítulo II
CAPÍTULO II: ANÁLISIS DE LOS PASOS A DESARROLLAR PARA UN SISTEMA DE CONTROL
DE GESTIÓN DE LOS PROYECTOS DE SOFTWARE DE LA FACULTAD TRES DE LA UCI.
Introducción
En el presente capítulo se analiza primeramente los resultados del diagnóstico al Control de Gestión
de los Proyectos de Software de la Facultad Tres de la UCI.
Luego se hace un análisis de la entrevista estructurada realizada al total de planificadores de los
proyectos en ejecución de la Facultad Tres de la UCI.
Además se hace un estudio de la factibilidad de las herramientas más utilizadas para la Gestión de
Proyectos, estableciéndose una comparación entre las mismas.
Finalmente se analizan los resultados de la entrevista no estructurada aplicada a los directivos de las
Direcciones de Producción 2 y 4 de la Infraestructura Productiva de la UCI.
2.1 Resultados del Control de la Gestión de los Proyectos de Software de la Facultad Tres de
la UCI.
El diagnóstico realizado al Control de la Gestión de los Proyectos de Software de la Facultad Tres de
la UCI se llevó a cabo a través de los siguientes métodos:
Se empleó el tipo de muestreo estratificado. Para un total de 15 proyectos con un total de 273
participantes, se tomó una muestra de 215 para un 95% de confianza.
La aplicación de este diagnóstico arrojó los siguientes resultados: (Delgado, 2007)
La Gestión de Proyectos de Software constituye una actividad protectora que determina los
elementos básicos para la concepción de cualquier proyecto de Software.
La integración de las funciones básicas de dirección de proyectos son los elementos claves
para desarrollar la Gestión de Proyectos de Software de forma exitosa.
Las cuatro P’s de Pressman que definen la Gestión de Proyectos de Software: Personal,
Producto, Proceso y Proyecto, se concretan en el proceso de Control de Gestión. Y a través
del análisis realizado al diagnóstico, se pudo evidenciar que las etapas de Planificación, y
Capítulo II
Capítulo II
Organización de los proyectos de Software de la Facultad Tres de la UCI, así como el
Liderazgo no están en función del logro del Control de Gestión de los mismos.
Se demostró que de los elementos que determina Pressman (Pressman, 2000) para una gestión
eficaz de un proyecto de Software que son personal, producto, proceso y proyecto, es al proceso
al que se debe controlar.
Una vez determinado el proceso clave a controlar se elaboró una entrevista cuyos resultados se
analizan a lo largo del epígrafe siguiente.
2.2 Análisis de la entrevista estructurada realizada al total de planificadores de Proyectos de
la Facultad Tres de la UCI.
En el presente epígrafe se exponen los resultados obtenidos de la entrevista realizada al 100% de
los planificadores de los proyectos de producción de Software de la Facultad Tres de la UCI. La cual
está compuesta por 12 preguntas (ver anexo 1).
La misma está encaminada a determinar elementos valiosos que tributen a la propuesta final:
Selección de áreas claves dentro del Proceso de Desarrollo de Software sobre las que se
deben actuar para una correcta gestión del mismo.
Identificación de las variables de gestión y de los documentos que deben de llevarse en el
Control de Gestión de los proyectos.
Determinar cuáles herramientas informáticas utilizan los proyectos de la Facultad para llevar
a cabo la gestión del mismo.
A continuación se muestran los resultados obtenidos:
La edad de los planificadores de proyectos oscila entre 21 y 24 años.
El 37,5% del total de planificadores cuentan con una experiencia de más de un año en el rol,
mientras que el resto cuenta con una experiencia que oscila entre 3 y 7 meses.
El 62,5% del total expresan que están de acuerdo con el rol que desempeñan, el 37.5% restante
prefieren trabajar en otros roles.
Capítulo II
Capítulo II
El 87,5% del total de los proyectos utilizan herramientas informáticas para la gestión de los
mismos, de ellos el 71,4% hacen uso del DotProject, un 28.5% usa el MS-Project y un 14.2%
utilizan Trac.
El 87,5% de los entrevistados han trabajado con el Parte de Producción3 que medía el Proceso
de Desarrollo de Software en la Facultad Tres de la UCI.
El 14.28% expresaron que el proceso de planificación y control que se lleva en sus proyectos no
tributaba a dicho parte; un 28.57% enunciaron que si tributaba; y un 57,14% plantea que
tributaba “más o menos”. Estos últimos, manifiestan que existían varios aspectos que a su
consideración son innecesarios y que no deben medirse de la forma en que se lleva a efectivo el
proceso.
El análisis que viene a continuación se basa en la determinación del nivel de concordancia que
tienen los planificadores de proyectos en cada uno de los aspectos que mide el parte de
producción. Para un 87.5% que representa el total de proyectos que han implementado dicho
parte se obtuvo lo siguiente:
De todos los aspectos que mide el parte (ver anexo 2), y de acuerdo al nivel de concordancia de
las personas entrevistadas, se pudieron identificar varias áreas importantes a medir durante el
desarrollo de un proyecto de Software (figura 4).
Fig. 4 Nivel de concordancia con los aspectos del parte de producción
3&%'(%)
"* +,
Capítulo II
Capítulo II
Para el análisis de los aspectos representados en la figura 4 solo se consideraron los más
significativos, es decir, aquellos para los cuales más de la mitad del criterio de los planificadores
coincidieron en su aceptación.
- Se puede apreciar en la figura 5 que el 100% de los planificadores de proyectos están de
acuerdo con los aspectos 2 y 4, y que el 85.71% con los aspectos 1 y 3.
Fig. 5 Nivel de concordancia con los aspectos del 1 al 4
Estos aspectos permiten caracterizar al proyecto a si está cumpliendo con lo que se planificó
para un determinado período de tiempo.
Destacar que del total de entrevistados que estuvieron de acuerdo con los aspectos 1 y 2 el 50%
de ellos plantearon que estos datos no debían ser mensuales, quizás de un período de 15 días o
menos, ya que determinar los hitos y puntos de control de un mes entero es algo que a veces no
está claro, y el proceso de definición de los mismos varía en acuerdo a las condiciones bajo las
cuales se desarrollan.
Como conclusión del análisis de estos primeros cuatro aspectos: queda identificada la primera
área del proceso a ser controlada: La Planificación.
- La figura 6 muestra que la mayoría de los entrevistados están de acuerdo con los aspectos del
12 al 17, los cuales son referentes a las no conformidades requeridas por los clientes. El
coeficiente de concordancia oscila entre el 71.43% y el 100% del total de entrevistados.
Capítulo II
Capítulo II
Fig. 6 Nivel de concordancia con los aspectos del 12 al 17
Como se puede observar en la figura 6, los planificadores entrevistados están de acuerdo con
que se controlen el estado en que se encuentran las solicitudes de cambio realizadas, dígase en
esperas analizas, en desarrollo, en revisión, en mejoras de post revisión y las cerradas.
Como conclusión del análisis de estos aspectos queda identificada la segunda área clave del
proceso a controlar: Solicitudes de Cambio.
- En la figura 7 se puede observar que el 100% de los entrevistados coinciden con el aspecto 19,
el cual hace referencia a la cantidad de casos de pruebas que han sido aplicados y validados.
Fig. 7 Nivel de concordancia con el aspecto 19
Del análisis de este aspecto también queda definida
la tercera área, como otra a ser controlada dentro
del proceso: Pruebas de Calidad.
Capítulo II
Capítulo II
- En la siguiente figura 8 están representados los aspectos 30 y 31, los cuales son referentes a la
capacitación del equipo del proyecto, ambos con un valor de 85.71% de acuerdo respecto al total
de entrevistados.
Dígase capacitación al total de cursos optativos impartidos por el proyecto en función de elevar
los conocimientos de sus integrantes para el correcto desarrollo del mismo.
Fig. 8 Nivel de concordancia con los aspectos 30 y 31
A partir de los resultados obtenidos de los elementos ya enumerados que miden de alguna forma
atributos4 de determinadas áreas durante el Proceso de Desarrollo de un proyecto, se puede
evidenciar que, las áreas claves identificas como las más importantes a controlar son: Planificación,
Solicitudes de Cambio, Pruebas de Calidad y Capacitación de RRHH.
El análisis de la pregunta 8 de la entrevista tributó también a la selección de otras áreas a
controlar durante el Proceso de Desarrollo de Software, donde las personas entrevistadas
consideraron de importancia.
La tabla 1 que se muestra a continuación evidencia el nivel de concordancia por proyectos en las
áreas propuestas por cada uno de los entrevistados:
- .% atributo /$"0
!1
Del análisis de estos aspectos se puede identificar
la cuarta área a ser controlada, a la cual los
entrevistados le atribuyeron gran importancia:
Capacitación de RRHH.
Capítulo II
Capítulo II
Otros aspectos /
proyectos
CE ERP RN ONE FGR CCV IIP MENPET Porciento de
ocurrencia
Captura de requisitos x x x x 66.6
Cantidad total de
elementos de
configuración del
proyecto
x
16.6
Certificación por
roles
x 16.6
Porcentaje de
ausencias
semanales de los
integrantes
x
16.6
Perspectiva del
cliente
X x x 50
Fase por la que va el
proyecto
x 16.6
Número de iteración
respecto a la fase
x 16.6
Cantidad de
revisiones técnicas
formales
x 16.6
Gestión de riesgos x x x 50
Tabla 1. Aspectos adicionales. Nivel de coincidencia por proyectos
Los datos mostrados en la tabla 1 han sido representados en un diagrama de barra (figura 9) de
manera que permitan emitir criterios sobre cuáles son las áreas claves identificadas por ellos.
Fig. 9 Nivel de concurrencia con los aspectos adicionales
Capítulo II
Capítulo II
Según el nivel de concordancia estas son:
-Captura de Requisitos. Varias personas expresaron que se deberían incluir aspectos
referentes el nivel de conocimiento que tenga el equipo de proyecto para analizar y
comprender los requisitos especificados por el cliente, en función de una correcta captura de
los mismos. Otros opinaron que una buena gestión de requisitos contribuía en gran medida al
éxito del proyecto. Por tanto, queda definida la quinta área del Proceso de Desarrollo de
Software a ser controlada.
-Perspectiva del Cliente. Se decidió nombrar esta área así debido a varios de los criterios
obtenidos. Algunos entrevistados opinaron que la satisfacción del cliente era algo primordial,
que era necesario medirlo de alguna manera. Otros manifestaron que hay que “ganarse” a
los clientes, en el buen sentido de la palabra, haciendo en tiempo y correctamente el
producto Software que ellos requieren.
Esta área identificada, es un elemento a analizar como resultado del desarrollo del producto,
y una vez terminado el mismo. Por lo que se considera que está totalmente fuera Proceso de
Desarrollo de Software, que constituye el proceso sobre el cual se va a accionar.
-Gestión de Riegos. El análisis de este aspecto permite observar la importancia que varios
de los entrevistados le atribuyeron al mismo, consideran que todo lo que se haga durante el
desarrollo de un proyecto debe verse afectado y analizado por los posibles riesgos que
puedan presentarse. Lo cual conlleva a hacer en esta área un correcto análisis y seguimiento
de los posibles riesgos a mitigar en el ciclo de desarrollo. Por tanto, queda definida la sexta
área del Proceso de Desarrollo de Software a ser controlada.
En la tabla 2 que se presenta a continuación se muestran los resultados obtenidos de la pregunta
10 de la entrevista: Documentos que considere deben de llevarse para el Control de la Gestión
de Proyectos.
Capítulo II
Capítulo II
Documentos de
gestión / proyectos
CE ERP RN ONE FGR CCV IIP MENPET Porciento de
ocurrencia
Parte de producción x x 25
Documento visión x x x 37.5
Plantilla RRHH x 12.5
Plan de trabajo x x 25
Plan de desarrollo
de software
x 12.5
Lista de riesgo x 12.5
Plan de mitigación x 12.5
Plan de iteraciones x 12.5
Elementos de
configuración
x 12.5
Documento de roles
y responsabilidades
x 12.5
Artefacto de
capacitación
x 12.5
Cronograma de
proyecto
x 12.5
Expediente de
proyecto
x x x x 50
Tabla 2. Respuestas a la pregunta 10 de la entrevista
Como se puede apreciar el 50% de los entrevistados coinciden en que los documentos que
deben llevarse para el Control de Gestión de los proyectos son los que están en el expediente de
proyecto definidos por la Universidad; por lo cual, como conclusión, se le atribuye gran
importancia a la existencia del mismo. “El Expediente de Proyecto es un entregable a controlar”
La tabla 3 que se muestra a continuación es referente a la pregunta: Qué variables usted
considera que deben de llevarse en el control de dicho proceso.
Variables de
gestión /
proyectos
CE ERP RN ONE FGR CCV IIP MENPET Porciento
de
ocurrencia
Tiempo x x x x 50
Alcance x x 25
Costo x 12.5
Riesgos x x x x 50
Calidad x x x x x 62.5
Tabla 3. Respuestas a la pregunta 11 de la entrevista
En dicha tabla se puede apreciar que el 50% de los entrevistados consideraron al tiempo y a los
riesgos como una de las variables más importantes que debe de manejarse en el control de este
Capítulo II
Capítulo II
proceso, mientras que un 62.5% le atribuyeron valor a la variable calidad. El resto de las variables
están entre valores de 12.5% y 25% de coincidencia respecto al criterio del total de entrevistados.
De una forma u otra todas las variables son elementos importantes a controlar en el desarrollo de
proyectos, por lo que alcance, y costos deben ser medibles también, pero se debe enfatizar más en
el control del tiempo, de los riesgos y de la calidad.
Dentro de los procedimientos que proponen los entrevistados para llevar un control eficiente de la
Gestión de Proyectos de Software de la Facultad Tres se puede observar que: el 25% no tiene
opinión, y el 75% restante que representan a 6 planificadores expresan lo siguiente:
- Parte de producción.
- Excel de planificación personal.
- Excel de cumplimiento de la planificación de las tareas del proyecto.
- Parte de producción es buena idea, haciéndole algunos arreglos.
- Uso de herramientas, plan resultado, control del plan de desarrollo de Software, chequeo de
proyectos periódicos.
- Los procedimientos que existen están bien, con esos son suficientes, pero no se hacen con la
calidad requerida, las herramientas no se usan como deben ser o simplemente la persona
que lleva el proceso no está lo suficientemente preparada.
Como resultado de esta pregunta a cada encuestado se puede observar que el 50% opina que debe
existir un mecanismo que le permita observar a la dirección de producción el estado de avance en
los proyectos, que puede ser a través de (parte o chequeos). Otro aspecto a observar, es que el 66%
de los encuestados consideran la necesidad del uso de una herramienta que lleve el proceso de
planificación de las tareas, tanto personales como en equipo.
Se pudo concluir a partir de los resultados obtenidos del presente epígrafe los diferentes elementos
a tener en cuenta para desarrollar un procedimiento en el Control de Gestión de los proyectos de
Software de la Facultad Tres de la UCI: áreas claves del Proceso de Desarrollo de Software;
posibles herramientas a utilizar; variables a medir; y documentos o entregables a controlar.
Capítulo II
Capítulo II
2.3 Factibilidad de las herramientas existentes para la Gestión de Proyectos
La elaboración de proyectos cada vez más complejos ha traído como consecuencia que su
planificación, organización y control se hayan hecho más complicadas, por lo que la dirección del
mismo necesita introducir técnicas de planificación y control más eficientes, que sean capaces de
facilitar la gestión de los proyectos e incrementar la calidad del proceso de ejecución.
Se deben introducir técnicas que puedan predecir problemas y permitan realizar las acciones
alternativas que sean necesarias, donde se tengan en cuenta los factores críticos en un proyecto
como son: tiempo, presupuesto y rendimiento, lo cual garantiza la ejecución del proyecto en el
tiempo comprometido, con los recursos planificados y la calidad requerida, lograrlo es la máxima
aspiración de todo líder de proyecto.
Diagramas de Barras (Gantt)
El diagrama de Gantt es uno de los más usados en la actualidad, tanto, que la mayoría de las
herramientas que han surgido desarrollan dicho método.
Para poder generar un calendario de proyecto utilizando gráficos Gantt, primero se tiene que
identificar las tareas que deben planificarse. Luego se determina la duración de cada tarea a través
de técnicas y fórmulas para la estimación apropiada de tiempos y por último determinar las
dependencias entre dichas tareas.
Este diagrama consiste en una representación gráfica sobre dos ejes:
- En el eje vertical se disponen las tareas a realizar del proyecto, cada una con una línea
horizontal correspondiente donde la longitud es proporcional a su duración.
- En el eje horizontal se representa el tiempo a través de un calendario o escala de tiempo,
haciendo uso del término de la unidad más adecuada al trabajo que se va a realizar, puede
ser en hora, día, semana, mes, etcétera.
El diagrama de Gantt suele utilizarse para mostrar el avance de los proyectos, en virtud de que
pueden comparar de forma conveniente la planificación original con el desarrollo real. Para informar
del avance del proyecto se tiene que ampliar las convecciones propias del gráfico de Gantt. Si una
tarea ha sido completada, su barra correspondiente aparecerá más oscura. Si ha sido completada
solo parcialmente, la parte proporcional de la barra estará más oscura. El porcentaje de barra
Capítulo II
Capítulo II
oscurecida debería corresponder al porcentaje de tarea completa. Las barras más claras simbolizan
tareas que no han sido empezadas. A continuación, se trazará una línea vertical perpendicular al eje
horizontal y que cortará a éste en la fecha del día. Entonces, se puede evaluar el avance del
proyecto.
En este diagrama las tareas del camino crítico se representan por un rectángulo de otro color, para
diferenciarlas de las demás actividades.
El diagrama de Gantt obvia las contradicciones en cuanto a recursos, ideal para proyectos sencillos
con trayectoria lineal; pero no es muy adecuado para la realización de cálculos. Es considerado un
instrumento de bajo costo y extrema simplicidad en su utilización para la planificación de actividades
relativamente simples. Sin embargo, para proyectos complejos, sus limitaciones son bastantes
serias.
Project Evaluation Research Task (PERT)
Un diagrama PERT está basado principalmente en la evaluación de programa y técnica de revisión,
el cual hace referencia a la representación gráfica de las relaciones entre tareas que constituyen el
proyecto, es uno de los métodos utilizados para la planificación que permiten programar y controlar
actividades con el fin de optimizar el proceso productivo.
Estos métodos introducen la planificación temporal, usados en sistemas de producción, compuestos
por diversas actividades ejecutadas en un orden temporal concreto y de las cuales se conoce su
duración. Además es muy útil cuando las actividades pueden ser realizadas en paralelo en vez de en
secuencia.
PERT trabaja con tiempos probabilísticos debido al nivel de incertidumbre en el tiempo de las
actividades de los proyectos para los cuales fue desarrollado, debido a la no existencia de bases de
datos para los tiempos de estas actividades.
El diagrama PERT es un grafo de precedencias donde los nodos son las actividades, y los arcos son
las relaciones de precedencia entre actividades. De cada actividad, se debe saber la duración
estimada y las actividades que le son precedentes. El resto surge casi automáticamente del mismo
diagrama.
PERT emplea tres estimados de tiempo para cada actividad, lo cual imposibilita que pueda ser
funcional en grandes proyectos, ya que ocupa mucho espacio de la memoria de las computadoras
Capítulo II
Capítulo II
actuales. Estos estimados de tiempo son los siguientes: tiempo optimista, tiempo probable, y tiempo
pesimista.
Con estos tres valores se calcula el tiempo de conclusión o duración esperada y la respectiva
varianza, donde el tiempo más probable es el tiempo requerido para completar la actividad bajo
condiciones normales. Los tiempos optimistas y pesimistas proporcionan una medida de la
incertidumbre inherente en la actividad, incluyendo desperfectos en el equipo, disponibilidad de
mano de obra, retardo en los materiales y otros factores.
Método del Camino Crítico (CPM)
Muy seguido al surgimiento del PERT, se desarrolló el método de la ruta crítica (CPM) para controlar
el mantenimiento de proyectos de plantas químicas, buscando el control y la optimización de los
costos de operación mediante la planeación adecuada de las actividades componentes de estos
proyectos.
El CPM es idéntico al PERT en concepto y metodología, por lo que la mayoría de los estudiosos del
tema lo tratan como PERT/CPM. La diferencia principal entre ellos es el método por medio del cual
se realizan estimados de tiempo para las actividades del proyecto.
Con CPM, los tiempos de las actividades son determinísticos y se pueden variar cambiando el nivel
de recursos utilizados, mientras que con PERT, los tiempos de las actividades son probabilísticos o
estocásticos. A diferencia de PERT, CPM se utiliza en proyectos con poca incertidumbre.
El conjunto de las técnicas PERT y el método del camino crítico proporcionan herramientas
cuantitativas que permiten determinar lo siguiente:
- El camino crítico del proyecto, que es la secuencia o cadena de actividades (que no tienen
ningún margen) que determina la duración total del proyecto.
- Las estimaciones de tiempos más probables, tanto para la totalidad del proyecto como para
el inicio y el final de cada una de las tareas o actividades individuales.
- Los márgenes de tiempo que se dan para cada tarea o actividad individual y que no
impliquen un retraso del proyecto.
Capítulo II
Capítulo II
Ms-Project 2003
Microsoft Project 2003 es un paquete de Microsoft Office, el mismo es un potente programa de
Gestión de Proyectos que se utiliza y demanda cada vez más por parte de las empresas, para crear
planes de proyecto, introducción de datos reales de evolución y realizar un completo seguimiento y
control de cada una de sus tareas, así como contabilizar la variación que se produce en el transcurso
de un proyecto respecto a lo que inicialmente se había programado.
Con este programa se gestionan y controlan tanto las tareas que integran un proyecto, como los
recursos que se utilizan para su desarrollo, además de las asignaciones recurso-tarea. Está
comprobado que con el Ms-Project el planificador del proyecto posee un control total del proyecto.
Con Microsoft Office Project, se puede dominar con rapidez el proceso de administración de
proyectos mediante la Guía de Proyectos, la cual consiste en una ayuda interactiva paso a paso que
permite configurar proyectos mediante asistentes, administrar tareas y recursos, realizar un
seguimiento de los procesos, así como crear informes a partir de la información de los proyectos.
Entre muchas posibilidades de trabajo, Ms-Project permite:
- Planificar y programar tareas así como asignar recursos a dichas tareas de manera adecuada
y sencilla.
- Realizar un control, organización y seguimiento, así como coordinar toda la información que
conlleva los requisitos del proyecto, la duración y los recursos asignados a las diferentes
tareas.
- Visualizar el Plan de Proyecto en formatos estándar y con un diseño de diagramas muy
apropiado y fácil de interpretar.
- Establecer escenarios dentro del proyecto para crear análisis de hipótesis. Planteamientos
del tipo "Que pasaría si...".
- Intercambiar información de proyecto con todos sus participantes a través de una red local,
Internet o de una Intranet.
Lo más importante del Ms-Project para la ayuda a la planificación de proyectos es que ofrece la
posibilidad de mostrar el método CPM y el diagrama PERT. Ambas técnicas desarrollan una
descripción de la red de tareas del proyecto, es decir, una representación gráfica o tabular de tareas
Capítulo II
Capítulo II
que deben realizarse desde el principio hasta el final del proyecto. También ofrecen una gestión de
recursos completa y un conjunto de diagramas y mecanismos de control que permiten realizar una
presentación brillante y muy profesional de la planificación de un proyecto.
Gantt Project
Gantt Project es una herramienta de uso libre con una interfaz similar al Ms-Project pero mucho más
ligera. Basa su contenido en una representación gráfica (Representación Gantt) para programar,
organizar las tareas y asignar personas y recursos, además de facilitar una visualización amena del
estado de progreso de cada actividad. Esta herramienta permite definir los días libres que tiene
asignados cada trabajador, así como los generales, y ofrece además una pequeña implementación
muy simple del diagrama Pert.
Gantt Project está programado en Java y funciona en Windows, Linux, MacOSX y otros sistemas
operativos que soporten Java; genera archivos XML, pero permite generar otro tipo de formatos
como: jpg, png, html, pdf y csv. Es una herramienta de código libre, se puede modificar, implementar
características que falten, añadir informes, entre otros.
DotProject
DotProject fue creado con el objetivo de construir una herramienta para la planificación, gestión y
seguimiento de múltiples proyectos para clientes diferentes, quienes pueden disponer también de
acceso para monitorizar la evolución del desarrollo de dicho proyecto. Es una herramienta gratuita,
construida por aplicaciones de código abierto, que incluye módulos para compañías, proyectos,
tareas (con gráficas de Gantt), foros, archivos, calendario, contactos, ticket y soporta distintos niveles
de permisos de uso de módulos.
Es una aplicación basada en web, multiusuario, soporta varios lenguajes y es Software libre. Está
programada en PHP y utiliza MySQL como base de datos, aunque puede ser utilizado también
Postgres. La plataforma recomendada para utilizar DotProject se denomina LAMP (Linux + Apache +
MySQL + PHP). Esta herramienta utiliza el diagrama de Gantt para representar el seguimiento y
control de sus actividades en un tiempo determinado. Está especializada en la administración de
proyectos por Internet e Intranet. Es fácil de instalar, configurar y aumentar, así como perfecto para
los pequeños y medianos grupos de proyectos que trabajen sobre sistemas extensamente
distribuidos.
Capítulo II
Capítulo II
DotProject se perfila como una interesante herramienta para trabajar en entornos colaborativos,
permitiendo a los integrantes del equipo trabajar online compartiendo información relativa a los
proyectos.
Algunas de las utilidades y herramientas de DotProject relacionadas con el control y monitoreo son:
-Administración de Tareas: Contiene las tareas necesarias para desarrollar un determinado
producto. Controla la duración, dependencias, recursos asignados y progreso.
-Diagrama de Gantt: Permite ver en forma gráfica las actividades ordenadas jerárquicamente,
mostrando las dependencias y solapamientos de las mismas.
-Recursos: Permite asignar recursos no humanos (oficinas, equipamiento, etcétera) a un
proyecto.
-Seguimiento de errores: Brinda la posibilidad de dar seguimiento a todos los problemas
relacionados con el proyecto.
-Administración de versiones de ficheros y repositorio de ficheros: Permite almacenar archivos
dentro de un proyecto permitiendo un versionado básico de los mismos.
Dicha herramienta permite la generación de gran cantidad de informes, como por ejemplo:
- Las horas asignadas (por usuario o proyecto).
- Las horas asignadas y las realmente incurridas, para poder extraer porcentajes de trabajos
realizados y porcentajes de eficiencia en base a tareas completadas.
- Estado de un proyecto: tareas completas, tareas con desviaciones...
- Estadísticas sobre proyectos: el porcentaje de avance de las diversas tareas, las horas
incurridas por los usuarios, etcétera.
Trac
Trac es un sistema web multiplataforma, ligero y extensible, que integra varios componentes con
capacidades suficientes para la Gestión de Proyectos de desarrollo de Software. Es frecuentemente
usado en proyectos de Software libre. Incluye wiki, navegador de código fuente, gestor de tickets,
Capítulo II
Capítulo II
entre otras funcionalidades. Permite además la extensión de las mismas mediante un sistema de
plugins.
Con el wiki se pueden crear páginas web, y junto a este la información que se considere necesaria.
El navegador de código es muy importante, ya que le permite a cualquiera ojear el desarrollo del
código fuente.
En base al gestor de tickets es posible el reporte de fallos y la sugerencia de funcionalidades. Con la
integración de cada una de las funcionalidades y posibilidades antes mencionadas se puede llevar a
cabo el seguimiento de un proyecto, con el objetivo de saber cuánto falta para alcanzar la meta
trazada en dicho proyecto.
La funcionalidad de administración del Trac permite realizar la gestión de varios aspectos del
proyecto, como son la configuración, usuarios, permisos, plugins, etcétera. Es también muy
importante el apartado de evolución, pues en base al repositorio de código, edición de wiki y gestión
de tickets, es posible la visualización de toda la evolución que tiene un proyecto.
En fin, esta herramienta es muy útil cuando se desea hacer una planificación perfecta de un proyecto
productivo de Software, ya que permite organizar y controlar todo el trabajo a realizar, posibilita
almacenar cada paso que se vaya haciendo y modificarlo sin perder la copia anterior. No sobrescribe
ningún código, ni documento, sino que siempre se crea una nueva copia del mismo.
Permite además, fragmentar el trabajo y luego volver a unir el módulo en que se esté trabajando. Es
una herramienta muy dinámica, que permite el trabajo rápido y fácil de manejar, además de
visualizar su seguimiento y control de una forma explícita, para así poder conocer en qué estado se
encuentra el proyecto en que se esté trabajando.
Agile Track
Es una herramienta de interfaz sencilla para planificación y seguimiento de proyectos, se utiliza
específicamente para el desarrollo de Software en equipos reducidos con metodologías ágiles,
especialmente “Extreme Programming”. Gestiona ciclos de desarrollo basados en iteraciones, con
seguimiento de historias de usuario, tareas y bugs.
Es multiplataforma, puede ser utilizado en Windows y Linux sin ningún problema. Consta de dos
módulos: el servidor que trabaja con MySQL, y el cliente para el seguimiento de los proyectos. Es un
desarrollo open source, de uso gratuito con licencia AFL (Academic Free License), el cual usa las
Capítulo II
Capítulo II
gráficas de Gantt para tener una visión del seguimiento del proyecto. Además, permite ejecutar una
demo del cliente completamente operativa desde la web del proyecto, sobre un navegador (Máquina
Virtual Java).
Todas las herramientas antes mencionadas permiten llevar acabo una planificación detallada de las
actividades que se realizan en un proyecto de Software, además posibilitan visualizar su
seguimiento, para así poder llevar un control pleno de estas tareas, para que el Software se obtenga
con la calidad requerida.
OpenWorkbench
Open Workbench es una herramienta de planificación de proyectos, al estilo de Microsoft Project. Se
ejecuta en entornos Windows y es completamente libre y gratuito. Soporta un amplio abanico de
funciones tales como la asignación de tareas hacia delante y hacia atrás, análisis de hitos, y tiempo
estimado para la terminación de la solución. Posee una habilidad única de programar tareas de
acuerdo a restricciones de recursos, y esta es una variedad nueva con respecto a otro Software de
planificación de proyectos. Esta característica ofrece un plan mucho más real y utiliza menos tiempo,
pues calcula la duración de la tarea en esfuerzo por disponibilidad de recursos. Entre sus principales
inconvenientes está que solo funciona con Windows, por tanto es imposible de usar para usuarios
amantes de Linux u otros Sistemas Operativos. Sin embargo es una herramienta que al ser open
source viabiliza el problema de licencias en Cuba que es un tema tan complicado. Adaptable al
entorno de trabajo con tan solo modificar cualquiera de sus componentes.
Project KickStart
Es una herramienta poderosa y fácil de usar que puede ayudar a los administradores de un proyecto
a diseñar, organizar y programar el mismo.
Project KickStart, tiene un proceso de 8 pasos que ayuda a concentrar la atención en la estructura
del proyecto, los objetivos, los recursos, los riesgos y las cuestiones estratégicas que son vitales
para el éxito de un proyecto. El resultado es que en 30 minutos el plan puede quedar listo.
Se puede programar el proyecto utilizando el calendario del menú descendente y la gráfica de Gantt.
Puede imprimir el listado de tareas o uno de los siete informes preestablecidos. O si lo prefiere, para
agregar versatilidad al proyecto se puede establecer un "enlace dinámico" de su información con
Microsoft Project o con otras herramientas.
Capítulo II
Capítulo II
Características y ventajas:
- Se puede utilizar en proyectos de cualquier tamaño - hasta 1000 tareas y 100 recursos.
- Se puede iniciar con ejemplos de proyectos, ya contienen información y están listos para
utilizarse.
- Listado de sugerencias en los archivos de Objetivos, Fases y Obstáculos, que usted puede
arrastrar con el Mouse y colocar en su proyecto.
- Gráfica de Gantt para programación completa.
- Siete tipos de informes preestablecidos.
- Archívelo como HTML, planeación post proyecto para su red interna.
- Enlace dinámico con Word, Outlook, PowerPoint y Excel para incluir sus proyectos en la
planeación de sus propuestas y planes de negocio.
Tutos
Tutos (The Ultimate Team Organization Software) es una herramienta web de código abierto y uso
gratuito para la gestión de pequeños grupos de trabajo o departamentos. Incluye calendario, gestión
de equipos, directorio de personas, gestión de incidencias, registro de tiempo, lista de seguimiento,
entre otras facilidades de trabajo.
ToDoList
Es una herramienta gratuita muy simple y efectiva para la Gestión de Proyectos en entornos ágiles.
Escasamente ocupa 1 Mb5 de capacidad, y al instalarla se puede indicar que emplee un único
fichero para guardar la información, de forma que no toca para nada el registro de Windows y se
puede llevar incluso en una memoria USB.
B-kin Project Monitor
B-kin Project Monitor es un Software de Gestión de Proyectos online que ayuda a monitorizar
proyectos, tareas, personas, perfiles, áreas, trabajos, costes, compras, entregables, documentación,
2
Capítulo II
Capítulo II
foros, entre otros. Es una herramienta propietaria. Provee una visión permanentemente actualizada
del avance de los proyectos y tareas, los impactos sobre los costes y el uso de los recursos.
Entre sus funcionalidades se encuentran:
- Planificación de tiempos, costes, recursos humanos, esfuerzos, trabajos, etcétera. Para esto
incorpora herramientas como: diagramas de Gantt, planificadores rápidos de tareas y
recursos, tareas predecesoras, bloqueo de planificación.
- Control a proyectos y tareas. Gestiona el avance, plazos, costes, esfuerzos, recursos (grupos
de personas, perfiles y personas), y consulta a los informes necesarios sobre la Gestión de
Proyectos.
- Ofrece información sobre cada elemento y la brinda de diferentes formas: documentos, foros,
informes, listados y otros, lo cual aporta valor al proyecto.
- Brinda más de cincuenta informes, configurados en por defecto, sobre esfuerzos y costes.
Además permite configurar y compartir los informes personalizados que se generen.
- Gestión eficaz y fácil a las tareas. Planifica los plazos, recursos y esfuerzos de cada tarea en
la Gestión de Proyectos.
- Controla los cambios que se producen. Modifica fácilmente los plazos, recursos y esfuerzos.
Actualiza la información de las tareas, reasigna y controla su avance contra el tiempo y
permite imputar las horas de esfuerzo mediante los partes horarios.
- Perfiles de usuario: Cada tipo de usuario del Software de Gestión de Proyectos
(responsables de programas, jefes de proyecto o de área, responsables de tareas
intermedias o personas que realizan los trabajos) obtiene la información de Gestión de
Proyectos asociada y accede a opciones según sus permisos y responsabilidad.
B-kin ofrece las siguientes ventajas: Es online, flexible, multiplataforma, seguro (es
responsable del alojamiento del Software, lo que garantiza seguridad y confidencialidad de la
información), completo (ofrece el sistema más avanzado para la planificación de esfuerzos,
costes y RRHH) es multiproyecto (agrupa los proyectos en módulos o grupos, lo que permite
su fácil análisis) y es colaborativo.
B-kin Project Monitor genera automáticamente informes sobre RRHH y materiales asignados a los
proyectos en curso. Brinda una visión actualizada de la situación de los proyectos y ofrece una
Capítulo II
Capítulo II
solución completa para la Gestión de Proyectos ya que presenta varios módulos como son: (B-kin
Project Monitor, Mi BPM, B-kin Purchase Report, B-kin Work Report) lo que facilita su posterior
planificación y realización. Permite exportar los datos a Ms-Project y Excel y es compatible con
aplicaciones online B-kin.
Rinde
La Red Nacional de Integración y Desarrollo de Software Libre (RINDE), surge en el año 2006 como
punto de encuentro para la producción y mantenimiento de aplicaciones informáticas, y con el fin de
estimular el desarrollo y consolidación de la industria del Software libre en la República Bolivariana
de Venezuela.
Es una plataforma de intercambio y colaboración de servicios especializados que ofrece una
infraestructura básica para las gestiones del conocimiento relativo a las tecnologías de información
libres y abiertas.
La misma ayuda a gestionar todo el ciclo de vida de desarrollo de los proyectos de Software. Posee
herramientas para ayudar al equipo a colaborar, como foros de discusión y listas de correo;
herramientas para crear y administrar repositorios de los ficheros de los proyectos utilizando CVS
(Concurrent Version System) o Subversion. Permite registrar items acerca de los proyectos y darles
seguimiento, tales como errores, correcciones, solicitudes de ayuda o solicitudes de nuevas
funcionalidades, pudiendo definir más, con "ilimitado" número de categorías, campos de texto,
etcétera.
Herramientas adicionales:
- Gestión de Releases de Ficheros.
- Herramienta para la Gestión de Proyectos.
- Publicación de Recortes de Código.
- Gestión de Documentos.
- Publicación de Noticias.
- Encuestas a Usuarios, Desarrolladores y Administradores.
- Administración de Miembros, Roles, Referencias, etcétera.
Capítulo II
Capítulo II
- Administración de Tareas.
- Búsquedas Simples y Avanzadas.
- Reportes y Estadísticas.
Nuestra Universidad está tratando de integrar a todas las Facultades en el trabajo de Software libre,
por lo cual necesita de una herramienta capaz de gestionar varios proyectos a la vez, donde sus
integrantes sean capaces de trabajar al mismo tiempo.
Actualmente se está haciendo un estudio de la plataforma RINDE, tratando de adaptarla a las
necesidades de la Universidad, pero aún se encuentra en una etapa de prueba y diagnóstico. Y
hasta que la misma no sea puesta en práctica no se sabrá cuán efectiva pueda ser su
implementación de tecnologías libres a través de su desarrollo colaborativo y el mantenimiento de
aplicaciones informáticas a las condiciones de cada uno de los proyectos de la UCI.
2.3.1 Comparación entre las Herramientas
Leyenda:
1. Alcance
2. Facilidad de uso
3. Tipo de aplicación
4. Garantiza la seguridad y confidencialidad de la información
5. Multiplataforma
6. Grado de integración con otras herramientas
7. Gratis
8. Software Libre
9. Código Abierto
10. Cantidad de proyectos de la Facultad Tres que la utilizan (expresado en porciento)
Capítulo II
Capítulo II
Herramientas 1 2 3 4 5 6 7 8 9 10
Diagrama de
Gantt
Proyectos simples
y medianos
alta - no si bajo - - - 0%
PERT Proyectos simples
y medianos
alta - no si bajo - - - 0%
CPM Para proyectos con
poca incertidumbre
alta - no si bajo - - - 0%
MS-Project
2003
Todo tipo de
proyecto
media desktop si no alto no no no 28.5%
Gantt Project Todo tipo de
proyecto
media web si si bajo si si si 0%
DotProject Todo tipo de
proyecto
media web si si alto si si si 71.4%
Trac Todo tipo de
proyecto
media web si si alto si si si 14.2%
Agile Track Todo tipo de
proyecto
media web si si medio si no si 0%
Open
Workbench
Todo tipo de
proyecto
media desktop si no bajo si si si 0%
Project
KickStart
Proyectos simples
y medianos
media desktop si no alto si no no 0%
Tutos Proyectos simples
y medianos
media web si si medio si no si 0%
ToDoList Proyectos simples
y medianos
media web si si medio si si si 0%
B-kin Project
Monitor
Todo tipo de
proyecto
media web si si alto no no no 0%
Rinde Todo tipo de
proyecto
media web si si alto si si si 0%
Tabla 4. Comparación entre las Herramientas. Fuente: Elaboración Propia
2.3.2 Herramienta Seleccionada
Muchas son las herramientas que existen en el mercado para apoyar y mejorar la planificación,
administración, control y seguimiento de los proyectos de producción de Software. En este epígrafe
se hizo un profundo estudio y análisis de la factibilidad de algunas de las más utilizadas actualmente
a nivel mundial para realizar dichas tareas.
Se analizó además el caso particular de la herramienta Rinde, que más que una herramienta, es una
plataforma de intercambio y colaboración, que ayuda en la gestión de todo el ciclo de vida de
desarrollo de un proyecto de Software. Y que como se evidenció, se encuentra en una etapa de
Capítulo II
Capítulo II
prueba, por lo que aún no se ha podido apreciar cuán eficiente puede ser la utilización de la misma,
en las necesidades de la Facultad Tres de la UCI.
Luego de establecer una comparación entre las herramientas se puede concluir que: debido a sus
características; funcionalidades en las condiciones actuales de los proyectos; y a la necesidad de
efectuar un control eficiente, es DotProject la que más se ajusta en el momento de la presente
investigación.
Para la selección de dicha herramienta, luego del estudio realizado, fue suficiente el criterio de
comparación entre las mismas teniendo en cuenta sus características, funcionalidades y
aprovechamiento. A partir de aquí se hizo una preselección predominando el criterio de
funcionalidades, donde quedaron tres de las herramientas candidatas: Trac, Rinde y DotProject.
Finalmente, el aspecto determinante que contribuyó a la selección de la herramienta propuesta, se
obtuvo de los resultados arrojados en la entrevista realizada al total de planificadores de los
proyectos de la Facultad Tres. De acuerdo al criterio de aprovechamiento, un 71,4% expresan que la
herramienta más empleada para el control y la gestión de sus proyectos es el DotProject.
DotProject es una herramienta que como bien se caracterizó es fácil de uso y manejo. Además es
multiplataforma, gratis y Software libre. Lo cual hace que su empleo sea muy importante para cubrir
las licencias de uso legal en nuestro país, ya que debido al bloqueo impuesto por el gobierno de
EE.UU ha obligado a Cuba a prescindir de diversos Software por razones de legalidad, costos y
licencias.
Dicha herramienta al ser código abierto permite adaptar sus funcionalidades al entorno de trabajo en
el cual se va a implantar, y la misma va a apoyar grandemente a la política de migración al Software
libre planteada por la Universidad, la cual ya está siendo implantada en muchos proyectos de la
Facultad Tres.
2.4 Análisis de la entrevista no estructura aplicada a las Direcciones de Producción 2 y 4 de la
Infraestructura Productiva de la UCI.
A partir del análisis de los resultados de la entrevista no estructurada realizada a los directivos de las
Direcciones de Producción (DP) 2 y 4, con el objetivo de obtener los elementos con los cuales
realizan el proceso de control a los proyectos a nivel de Facultad, de la misma se obtuvieron los
siguientes resultados:
Capítulo II
Capítulo II
- Estas DP se centran en atender programas, cada programa está compuesto por varias áreas
de resultados claves, y dentro cada área resultado pueden haber un número considerable de
proyectos, de diferentes Facultades.
- Los programas están orientados a los organismos (clientes); se detectan necesidades de
esos organismos y de ahí es donde salen las áreas de resultados claves.
- Las DP no utilizan indicadores para medir y evaluar el desempeño de los proyectos.
- Actualmente lo que hacen son chequeos con los organismos y la dirección del equipo de
proyectos en las Facultades.
- Aún no existe una proyección estratégica para atender a los proyectos a nivel de Facultad.
- Solo se realiza el control de los proyectos centrándose en el avance de los mismos, lo cual
permite verificar el estado en que se encuentran y el cumplimiento de sus cronogramas de
trabajo.
Los resultados de esta entrevista, permiten observar que no existen indicadores para el Control de la
Gestión de proyectos a nivel de Dirección de Producción. Por lo que fue necesario hacer un estudio
bibliográfico en la determinación de los mismos. Los principales autores son: (McGarry, 1998),
(Humphrey, 2000), (Pressman, 2000), (Humphrey, 2001), la norma ISO/IEC 9126 para calidad del
producto (Información, 2005), entre otros.
Capítulo II
Capítulo II
2.5 Conclusiones
Una vez concluido el presente capítulo se pueden declarar las siguientes conclusiones:
Los métodos de investigación utilizados permitieron obtener y definir las áreas claves del
Proceso de Desarrollo de Software que necesitan ser controladas para una correcta gestión,
se pudo obtener además como resultado de los mismos las variables de gestión hacia las
cuáles debe estar enfocado dicho control, se determinaron posibles herramientas de gestión
a utilizar y los documentos que deben de llevarse en este proceso.
Utilizar una herramienta informática para gestionar proyectos de Software es esencial para el
correcto desarrollo de este proceso. Seleccionar una u otra es necesario para estudiar el
grado de integración que debe de existir entre las características inherentes a las mismas y
las necesidades a satisfacer. Otro elemento indispensable para la utilización de esta es que
el equipo de proyecto la conozca y esté familiarizado con la misma.
El estudio de diferentes bibliografías permitió obtener los autores que definen indicadores
para medir áreas claves del Proceso de Desarrollo de Software.
Capítulo III
Capítulo III
CAPÍTULO III: PROPUESTA DEL PROCEDIMIENTO
Introducción
En el presente capítulo se propone un procedimiento para efectuar el Control de la Gestión de los
Proyectos de Software en la Facultad Tres de la UCI a partir de los resultados de los métodos
aplicados en el capítulo II.
3.1 Elementos fundamentales para la ejecución del procedimiento. Operacionalización de las
variables del mismo.
A partir del análisis teórico realizado en el capítulo I y de los resultados de los métodos descritos en
el capítulo II, la autora del presente trabajo determinó que ya contaba con todos los elementos para
proponer un procedimiento que permita llevar a cabo el Control de Gestión de los Proyectos de
Software de la Facultad Tres de la UCI.
Proceso clave a controlar: Proceso de Desarrollo de Software.
Áreas claves dentro de este proceso: Planificación, Solicitudes de Cambio, Pruebas de Calidad,
Capacitación de RRHH, Captura de Requisitos y Gestión de Riesgos.
Variables de gestión a controlar sobre las áreas claves: Tiempo, Riesgos y Calidad.
Indicadores para medir las variables de gestión: (ver tabla 5).
Documentos necesarios: Expediente de Proyecto.
Herramientas de apoyo a la gestión: DotProject.
Capítulo III
Capítulo III
Operacionalización de las Variables del Procedimiento
Variable
Conceptual
Dimensión Áreas del
proceso
Variable Dimensión Indicadores
Procedimient
o adecuado
para el
Control de
Gestión de los
Proyectos de
Software de la
Facultad Tres
de la UCI.
Proceso de
Desarrollo de
Software.
Planificación Tiempo Ejecución de las
tareas.
Porciento de tareas completadas.
Porciento de tareas no
retrasadas.
Porciento de error de estimación
de tiempo.
Riesgo Planificación del
trabajo.
Horas planificadas por cada
integrante.
Calidad Planificación y
ejecución de
proceso.
Nivel de significación del valor de
los indicadores Tiempo + Riesgo.
Solicitudes
de Cambio
Tiempo Ejecución del
proceso de
cambios.
Duración del proceso.
Riesgo Ejecución del
proceso.
Gráficos de análisis del estado de
los pedidos de cambio.
Calidad Ejecución del
proceso.
Nivel de significación del valor de
los indicadores Tiempo + Riesgo.
Pruebas de
Calidad
Tiempo Eficiencia de la
ejecución del
proceso de
pruebas.
Defectos eliminados por unidad
de tiempo.
Porciento del tiempo total
dedicado a las pruebas.
Riesgo Ejecución del
proceso de
pruebas.
Integridad de la implementación
funcional.
Cobertura de las pruebas.
Madurez de las pruebas.
Calidad Ejecución del
proceso de
pruebas.
Porcentaje de defectos por tipo.
Rendimiento de la eliminación de
defectos.
Nivel de significación del valor de
indicadores Tiempo + Riesgo.
Capacitación
de RRHH
Tiempo Ejecución del
plan de
capacitación.
Aprovechamiento del tiempo real
de capacitación.
Riesgo Ejecución del
plan de
capacitación.
Detección y análisis de las
necesidades de formación.
Cumplimiento del plan de
Capacitación.
Nivel de aprobación de las
pruebas de capacitación.
Calidad Ejecución del
plan de
capacitación.
Nivel de significación del valor de
los indicadores Tiempo + Riesgo.
Captura de
Requisitos
Tiempo Ejecución del
proceso de
análisis de
requisitos.
Tiempo invertido en el proceso de
análisis de requisitos.
Riesgo Análisis y
gestión de
requisitos.
Entendimiento de los requisitos.
Estabilidad de los requisitos.
Capítulo III
Capítulo III
Calidad Análisis, gestión
y ejecución del
proceso.
Nivel de significación del valor de
los indicadores Tiempo + Riesgo.
Gestión de
Riesgos
Riesgo Ejecución del
proceso en la
gestión de
riesgos.
Medición de la identificación de
los riesgos.
Probabilidad de que ocurran
riesgos de un mismo tipo.
Efectividad de la mitigación de
riesgos.
Tabla 5. Operacionalización de las variables del procedimiento. Fuente: Elaboración Propia
Pasos del Procedimiento Propuesto
3.2 Objetivo
Desarrollar el proceso de Control de Gestión en los Proyectos de Software de la Facultad
Tres de la UCI, a través de la medición de áreas claves dentro del Proceso de Desarrollo,
indicadores que permitan medir dichas áreas a través de variables de gestión, documentos
entregables y herramientas de soporte para la evaluación del proceso.
3.3 Alcance
Proyectos de Producción de Software en la Facultad Tres de la UCI.
3.4 Responsables
La dirección de producción de la Facultad Tres tiene la máxima responsabilidad de que cada Jefe de
Polo lleve a efecto la presente propuesta en cada uno de sus proyectos. Y cada Líder de proyecto
acompañado del Planificador debe realizar el estudio de cómo ajustar el proceso en su organización,
para hacer efectivo el mismo en la práctica.
Cada una de las partes de la jerarquía de responsabilidad representada en la figura 10, serán las
encargadas de verificar y controlar que se le esté dando cumplimiento al Procedimiento.
Capítulo III
Capítulo III
Fig. 10 Jerarquía de responsabilidad en la ejecución del procedimiento. Fuente: Elaboración Propia
3.5 Desarrollo
3.5.1 Identificación de los Indicadores para el Procedimiento
Para cuantificar el comportamiento del Proceso de Desarrollo, los cuales son generalmente objetivos
absolutos, explícitos y dinámicos, se utilizan métricas. Estas recopilan los datos del proyecto durante
un largo período de tiempo. Su propósito es proporcionar indicadores que lleven a mejoras de los
procesos medibles. Un indicador es una métrica o una combinación de métricas que proporcionan
una visión profunda del proceso del Software, del proyecto de Software o del producto en .
(Pressman, 2000)
Las mediciones que se deben aplicar a cada una de las áreas están encaminadas a señalar
tendencias (ya sean buenas o malas); a realizar mejores estimaciones; a llevar a cabo una
verdadera mejora sobre el tiempo, sobre la calidad del trabajo que se realiza; a detectar
desviaciones y ponerlas bajo control, todo lo cual va a llevar a una reducción del coste global del
proyecto. Todo esto bajo la perspectiva de que “Midiendo se podrá mejorar el rendimiento de todo
proceso”.
Planificación
La planificación es una de las áreas del Proceso de Desarrollo que hay que medir, darle seguimiento
y trabajar para mejorarla, ya que constituye una guía para la realización y el control del proyecto y
sus actividades, en ella se asignan las responsabilidades y recursos, se estiman las fechas de
Dirección de
Producción
Dirección de
Producción
Jefes de Polos Productivos
Jefes de Polos Productivos
Jefe Polo 2
Jefe Polo 2
Jefe Polo 1
Jefe Polo 1
Jefe Polo 3
Jefe Polo 3
Líderes y Planificadores de proyectos
Líderes y Planificadores de proyectos
Capítulo III
Capítulo III
cumplimiento a las tareas, negociación de compromisos, establecimiento de un calendario e
identificación y análisis de los posibles riesgos que pueda tener el proyecto.
Para lograr mejorar esta área es necesario igualar los resultados planificados y los reales.
Varios de los indicadores que se definieron para esta área se obtendrán de los informes y
estadísticas que genera la herramienta seleccionada para el apoyo a la gestión de los proyectos
(DotProject).
Porciento de tareas completadas
Es de vital importancia llevar un registro y mediciones de las tareas que se desarrollan durante el
proyecto, pues de esta manera pueden realizarse mejores asignaciones de recursos y tiempo, así
como tener una medida del progreso del trabajo realizado respecto al planificado teniendo en cuenta
el cumplimiento de las tareas en un determinado período de tiempo.
El porciento de tareas completadas (TC%) se calcula mediante la fórmula:
TC% = (TC / TP) * 100, donde:
TC: Número de tareas completadas.
TP: Número de tareas planificadas.
A medida que el porciento de tareas completadas se acerca al 100% será mejor, pues el número de
tareas completadas estará próximo al número de tareas planificadas.
Este indicador proporciona una medida de cuántas tareas se han completado con respecto a las
planificadas al acercarse un determinado hito o fase en el desarrollo del Software, siendo una
indicación del progreso alcanzado.
Porciento de tareas no retrasadas
No debe confundirse tareas retrasadas con tareas no completadas, una tarea se determina como
retrasada si la misma no se ha terminado y la fecha actual es mayor que la fecha tope de
finalización, también se considera retrasada si se ha concluido y la fecha real de finalización ocurre
después de la fecha tope planificada. Para una mejor comprensión vea la figura 11, teniendo en
cuenta que el tiempo planificado es de 5 días.
Capítulo III
Capítulo III
Fig. 11 Representación de las tareas respecto al tiempo. Fuente: Elaboración Propia
El porciento de tareas no retrasadas (TNR%) se calcula mediante la fórmula:
TNR% = ((TP - TR) / TP) * 100, donde:
TR: Número de tareas retrasadas.
TP: Número de tareas planificadas.
A medida que el porciento de tareas no retrasadas se acerque al 100% será mejor, pues significa
que pocas tareas se han retrasado respecto al tiempo planificado para su desarrollo.
Este análisis puede realizarse en cualquier momento del desarrollo del proyecto siempre que estén
fijadas las fechas de inicio y finalización de las tareas.
Porciento de error de estimación de tiempo
La estimación es una de las actividades prioritarias en la Gestión de Proyectos y es una forma de
medir la calidad de lo planificado, por lo que es importante estimar el tiempo basado en datos
históricos. Estos registros ayudarán a hacer mejores estimaciones de tiempo para trabajos futuros.
El porciento de error de estimación de tiempo (EET%) se calcula como:
EET% = ((TR - TE) / TE) * 100
EET = TR - TE
Donde:
TR: Tiempo real.
TE: Tiempo estimado.
TE -------100%
EET ----- EET%
Capítulo III
Capítulo III
En este indicador mientras menor sea el porciento de error de estimación de tiempo será mejor, pues
indicará que el error está oscilando en valores cercanos a cero, lo cual significa que el tiempo real
está próximo al estimado, por lo tanto no se ha sobreestimado o subestimado durante la
planificación. Si el valor del porciento es negativo significa que el tiempo real estuvo por debajo del
estimado y en caso contrario el tiempo real estuvo por encima del estimado.
Teniendo registros de cuanto puede desviarse el tiempo real respecto al planificado pueden
realizarse mejores estimaciones para futuros trabajos con características similares, de manera que
pueda minimizarse lo más posible el porciento de error en la estimación del tiempo.
Esfuerzo del personal
Para que el jefe de proyecto tenga más elementos a la hora de asignar, reasignar carga de trabajo y
analizar el esfuerzo del personal, se definió la siguiente medición del esfuerzo del personal:
-Horas planificadas de cada integrante del proyecto en la semana
Con un análisis del gráfico que se presenta en la figura 12 se puede lograr un análisis más profundo
de la asignación de esfuerzo, por ejemplo, se muestra que se le ha asignado demasiada carga a
“Hector” mientras que algunos de los miembros del equipo prácticamente no tienen trabajo, este
análisis es muy evidente y el jefe del proyecto decidirá si es correcto o no que suceda.
Los gráficos de esfuerzo del personal están basados en propuestas del PSM. (McGarry, 1998)
Fig. 12 Gráfico del esfuerzo del personal. Fuente: Elaboración Propia
Estos datos que se muestran en la figura 12 se obtienen luego de haber hecho la planificación
semanal de las horas que cada integrante del equipo debe dedicarle al trabajo en el proyecto (ver
anexo 3); y en dependencia de esto se asignará el trabajo a realizar por cada uno de ellos.
Capítulo III
Capítulo III
Solicitudes de Cambio
Gráficos de análisis del estado de los pedidos de cambio
En un proyecto de Software el cambio incontrolado puede llevar rápidamente al caos. La forma más
cómoda y visual de lograr un seguimiento a los pedidos de cambio que se solicitan a un sistema, es
a través de los gráficos del análisis del estado de los pedidos de cambio. Un ejemplo pudiera ser el
que se muestra en la figura 13. En este gráfico se puede llegar a la conclusión clara de en que
estado están estancado los pedidos de cambio y por tanto darle una advertencia al jefe del proyecto
de donde tiene que insistir e incluso si es necesaria una reunión de la junta de control de cambios.
Fig. 13 Estado de los pedidos de cambio. Fuente: Elaboración Propia
En la figura 13 están representadas las solicitudes de cambio en cinco estados diferentes:
- Realizadas por el cliente: Cantidad de solicitudes de cambio realizadas por los clientes.
- En análisis/desarrollo: Solicitudes de cambio aprobadas por la junta que están siendo
resueltas por un desarrollador.
- Aprobadas: Solicitudes de cambio que ya han sido aprobadas por la junta de control de
cambios pero no se han comenzado a desarrollar por un especialista.
- Rechazadas: Solicitudes de cambio que la junta tiene pendiente por tener incompleto los
datos.
- Cerradas: Cantidad de solicitud de cambio que ya fue resueltas.
Cada líder de proyecto define los estados de solicitudes que considere necesarios.
Capítulo III
Capítulo III
Duración del proceso
Es recomendable medir el tiempo que dura todo este proceso de solicitudes de cambio (TSC), es
decir, desde que el cliente realiza las solicitudes hasta que son cerradas por el equipo de proyecto e
ir guardando estos datos. De esta manera se podrá comparar y evaluar este indicador con el
resultado de otros proyectos, o también internamente dentro del mismo proyecto cada vez que se
repita dicho proceso.
Una vez que se tenga el TSC del proceso, se procedería a realizar el cálculo siguiente:
TSC = SCC / TSC, donde:
SCC: Cantidad de solicitudes de cambio que fueron cerradas.
A medida que el resultado de esta razón aumente, indicará que el equipo de proyecto está
trabajando en aras de en menor tiempo posible cerrar la mayor cantidad de solicitudes de cambio,
logrando de esta manera reducir tiempo de desarrollo y creando una mayor satisfacción al cliente.
Pruebas de Calidad
La etapa de prueba es tan o más importante que todas las vista hasta el momento, puesto que en
ella se refleja la calidad con que ha sido llevada a cabo la proyección del sistema. En esta etapa no
se puede asegurar la ausencia de defectos, solo puede demostrarse la existencia de los mismos.
Si un determinado producto de Software tiene tantos defectos que no se ejecuta con una
consistencia aceptable, el usuario final no lo usará, a pesar de otros atributos positivos que tenga.
(Humphrey, 1995). Es por ello que es necesario que lo mismos se eliminen antes de la entrega final
del producto, y que se trabaje en aras de introducir la menor cantidad de errores posibles durante
todo el Proceso de Desarrollo.
En todas las fases del desarrollo del proyecto hay que probar el Software que se va construyendo y
resulta muy importante definir un conjunto de mediciones para guardar los resultados de las mismas,
de manera que aporten información relevante para pruebas sucesivas.
Rendimiento de la eliminación de defectos
En cualquier etapa del Proceso de Desarrollo de Software se introducen defectos, en muchas
ocasiones son fácilmente identificados y eliminados. Se considera defectos evadidos a todos los
defectos que se insertaron antes o durante una etapa determinada, pero que no fueron encontrados
Capítulo III
Capítulo III
en esa etapa, sino en otra posterior, estos traen consigo una costosa inversión de tiempo y esfuerzos
para su eliminación. Este indicador se basa en la relación entre los defectos eliminados y todos los
existentes en una etapa determinada.
El rendimiento de la eliminación de defectos (R) se calcula mediante la fórmula:
R = (DE * 100) / (DE + DV), donde:
DE: Defectos Eliminados.
DV: Defectos Evadidos.
El objetivo o meta es lograr un rendimiento de 100%, o sea, que todos los defectos sean
encontrados y eliminados en la etapa que se esté analizando y se reduzcan los defectos evadidos.
Es importante tener identificados los posibles defectos que ocurran frecuentemente en una etapa o
fase determinada dentro del Proceso de Desarrollo, de manera que se pueda evitar o solucionar a
tiempo.
Para analizar el avance del rendimiento de un equipo de proyectos, un indicador eficiente es graficar
el rendimiento por cada etapa del proyecto, un ejemplo se muestra en la figura 14.
Fig. 14 Gráfico de avance del rendimiento. Fuente: Elaboración Propia
Una buena tendencia es la señalada en la figura 14, o sea, en la medida que el equipo de proyecto
gana en experiencia, el valor del rendimiento debe ir aumentando.
Capítulo III
Capítulo III
Defectos eliminados por unidad de tiempo
Los defectos siempre deben encontrarse y corregirse en el menor tiempo posible. Un indicador que
se propone para tener un control de la efectividad del tiempo dedicado a resolver los defectos es el
siguiente:
Los defectos eliminados por tiempo (DET) están dados por:
DET = N * DT / TD, donde:
TD: Tiempo invertido en la eliminación de defectos en una etapa, dado en la unidad de tiempo N.
DT: Defectos totales encontrados en una etapa.
N: Unidad de tiempo.
Los defectos por unidad de tiempo indican la efectividad del tiempo dedicado a las revisiones, así
como la eficiencia relativa de los múltiples métodos de eliminación de defectos que se estén usando.
Si los defectos encontrados por unidad de tiempo han disminuido y el rendimiento no se ha
incrementado, puede significar que se está dedicando mucho tiempo a revisiones improductivas. En
la medida que el rendimiento se incrementa, una disminución de los defectos por unidad de tiempo
es natural.
Porcentaje de defectos por tipo
El objetivo de este indicador es identificar los tipos de defectos más comunes que puedan
presentarse en cualquiera de las etapas del Proceso de Desarrollo del Software y así enfocarse más
en el tipo de defectos que ocurren con más frecuencia (tabla 6).
No. Tipo Defecto Descripción del tipo de defecto %
1Expresión inadecuada 6.3
2Asignación omitida 10.02
3Error sintáctico 19.1
4Algoritmo inadecuado 22.0
5
Tabla 6. Porcentaje de defectos por tipo. Fuente: Elaboración Propia
Este porcentaje sería de los tipos de defectos que se encontraron durante todo el Proceso de
Desarrollo, dígase en las revisiones, luego en las compilaciones, en las pruebas, etcétera.
El porcentaje de defectos por tipo (DT%) está dado por la siguiente ecuación:
Capítulo III
Capítulo III
DT% = (CDT / TTD) * 100, donde:
CDT: Cantidad de defectos por tipo.
TTD: Número total de defectos identificados en una etapa del proyecto.
Un alto valor del porciento de defectos por tipo indicará que el defecto analizado se presenta con
mucha frecuencia.
Realizando este cálculo se puede ordenar por porciento de ocurrencia los tipos de defectos más
comunes en el desarrollo de cualquier proyecto y así tenerlos identificados para no incurrir en ellos
durante futuros proyectos. Es una buena práctica revisar esta distribución periódicamente para
asegurarse que el foco sigue en los defectos que más se cometen.
Una forma también cómoda de analizar estos datos es a través de un gráfico donde los defectos son
ordenados con el tipo de defectos más frecuentes a la izquierda y así sucesivamente en orden
descendente.
Integridad de la implementación funcional
Durante la especificación de requisitos deben quedar definidas todas las funcionalidades que tiene
que cumplir un sistema, sin embargo, en ocasiones no se logra implementar cada una de ellas, ya
sea por descuido de los programadores o producto de una especificación ambigua, para comprobar
qué funcionalidades fueron o no implementadas se utilizan las pruebas de caja negra. El indicador
que se propone a continuación da una medida de cuán completa ha sido la implementación según la
especificación de requisitos.
La integridad de la implementación funcional (IIF) está dada por la siguiente ecuación:
IIF = 1 - (FP / FD), donde:
FP: Número de funciones perdidas detectadas en la evaluación.
FD: Número de funciones descritas en especificación de requisitos.
Se desarrollan las pruebas de caja negra de acuerdo con la especificación de requisitos. El número
de funciones perdidas detectadas son aquellas que fueron descritas en la especificación de
requisitos y no fueron implementadas. Mientras más se acerque a 1 el valor de IIF, será mejor, pues
significa que hubo un menor número de funciones perdidas.
Capítulo III
Capítulo III
Cualquier función perdida no puede ser examinada durante la prueba por cuanto no ha sido
implementada. Para detectar funciones perdidas, se sugiere que cada función recogida en la
especificación de requisitos sea probada una por una durante la prueba funcional. Los resultados
obtenidos se convierten en entradas para este indicador. (Información, 2005)
Este indicador puede ser muy útil pues evalúa la completitud de la implementación, si se tienen
muchas funcionalidades perdidas, no se habrá desarrollado una buena implementación, lo cual
implicará la toma de acciones correctivas para controlar este proceso, de manera tal, que no se vea
afectada la calidad del producto final.
Cobertura de las pruebas
Tan pronto como se hayan capturado los casos de uso de un sistema es posible identificar los casos
de prueba que verifiquen si el sistema está implementando las funcionalidades descritas en los
mismos, es decir, si cumple con los requisitos del sistema. La cobertura de las pruebas indica cómo
se van cumpliendo los casos de prueba especificados, por lo tanto, mientras mayor sea la cobertura,
mayor número de casos de prueba se estarán cumpliendo.
La cobertura de prueba (CP) está dada por la siguiente ecuación:
CP = CPE / CPR, donde:
CPE: Número de casos de pruebas que han sido realmente ejecutados.
CPR: Número de casos de prueba a ejecutar requeridos para cubrir los requisitos.
La cobertura será mejor mientras más se acerque a 1, esto significará que se están ejecutando la
mayor cantidad de casos de prueba de los que se habían propuesto.
La importancia que se le concede a este indicador es llevar un control del cumplimiento de los casos
de prueba requeridos para cubrir los requisitos, lo que por supuesto, da una medida de cuán
correctamente se está desarrollando el proceso de prueba.
Madurez de las pruebas
La madurez de las pruebas también es un indicador para medir qué tan bien se está desarrollando el
proceso de pruebas, no solo se preocupa de la completitud de los casos de prueba según los
definidos para cumplir los requisitos, sino que también se interesa por cuáles han obtenido
resultados satisfactorios, para ello es necesario llevar un control de los casos de prueba que
Capítulo III
Capítulo III
arrojaron resultados satisfactorios y el total de los casos de prueba definidos para el cumplimiento de
los requisitos.
La madurez de las pruebas (MP) está dada por la siguiente ecuación:
MP = CPS / CPR, donde:
CPS: Número de casos de pruebas que han obtenido un resultado satisfactorio.
CPR: Número de casos de pruebas a ejecutar requeridos para cubrir los requisitos.
Mientras mayor sea el número de casos de pruebas que han obtenido un resultado satisfactorio de
los casos realmente ejecutados y que se requieren para cubrir los requisitos, mayor será la madurez
alcanzada por el equipo de probadores del Software, lo ideal es un valor cercano a 1.
Este indicador conjuntamente con el anterior hacen referencia al factor confiabilidad definido en la
ISO 9126, específicamente al sub atributo de madurez. (Información, 2005)
Porciento del tiempo total dedicado a las pruebas
Este indicador da una medida del porciento del tiempo de desarrollo gastado en probar, o sea, del
tiempo dedicado a las pruebas respecto al tiempo total de desarrollo del proyecto. El tiempo de la
prueba será mayor mientras más defectos se hayan introducido en el Software, por este motivo se
recomienda trabajar cuidadosamente e ir haciendo revisiones durante todo el proceso para ir
eliminando los defectos que puedan surgir en las etapas tempranas y de esta manera se reduzca el
tiempo dedicado a las pruebas. El tiempo dedicado a las pruebas dependerá en gran medida del
tamaño y complejidad del Software que se esté desarrollando, los proyectos similares al analizado
tendrán una referencia para estimar el tiempo que deben emplear a las pruebas.
El porciento del tiempo total dedicado a las pruebas (TP%) se calcula como:
TP%= 100 * TTP / TTD, donde:
TTP: Tiempo Total de Pruebas.
TTD: Tiempo Total de Desarrollo.
Capítulo III
Capítulo III
Capacitación de RRHH
Uno de los factores más importantes que contribuyen al éxito de un proyecto de Software es el
personal, y por ende, la necesidad de contar con un personal altamente preparado para el desarrollo
de Software es un tema de gran importancia para una gestión eficaz de cualquier proyecto.
Para tener un control sobre esta área se definieron los indicadores siguientes:
Detección y análisis de las necesidades de formación
Identificar las necesidades de formación es fundamental antes de accionar y desarrollar una
estrategia encaminada a solucionar este problema; pero no se pueden identificar estas necesidades
deliberadamente, existen técnicas que facilitan esta actividad, las cuales son:
- Observación directa: se observa el lugar de trabajo y el desempeño.
- Reuniones de grupo: los Jefes exponen las necesidades generales e individuales del proyecto.
- Entrevistas: son para detectar las dificultades, buscar orígenes y determinar si están
relacionadas a la falta de formación.
Análisis para detectar las necesidades
- Análisis del equipo: está relacionado a la adquisición de tecnología y la necesidad de aprender a
utilizarla.
- Análisis de la actividad: son los cambios en la realización de nuevas actividades.
- Análisis de problemas: es para identificar problemas que se deban a la mala formación o a la
falta de conocimientos.
- Análisis del comportamiento: este tiene en cuenta el nivel de eficiencia del miembro del equipo.
- Análisis de la organización: es cuando se modifican las responsabilidades o las relaciones entre
los diferentes componentes de proyecto.
Ya una vez identificadas las necesidades del equipo de proyecto se procedería a realizar un plan de
capacitación y controlar y asegurar que se le de cumplimiento al mismo.
Capítulo III
Capítulo III
Cumplimiento del plan de capacitación
Una de las soluciones que puede plantearse un líder de proyecto ante las deficiencias en cualquier
área del Proceso de Desarrollo es impartir cursos de capacitación a los integrantes del proyecto,
para mejorar la preparación de los mismos. Es responsabilidad de la dirección del proyecto
asegurarse que se cumpla el plan de capacitación del proyecto y para ello se define el siguiente
indicador:
CAI =CUI / CUP, donde:
CAI: Capacitación impartida.
CUI: Número de cursos impartidos.
CUP: Número de cursos planificados.
Esta medida se utiliza para seguir los cursos impartidos respecto a los planificados. A medida que la
capacitación impartida se acerque a 1 o sobrepase este valor significará que se ha cumplido el plan
de capacitación del proyecto.
El objetivo de esta medida es asegurar que se impartan los cursos necesarios para el desarrollo
satisfactorio del proyecto. En caso que la cantidad de cursos impartidos sea menor que los
planificados, deben tomarse las acciones correctivas necesarias. Es responsabilidad de la dirección
del proyecto hacer el plan de capacitación en caso que lo considere necesario y una vez definido,
darle cumplimiento.
Nivel de aprobación de las pruebas de capacitación
Nivel de aprobación de las pruebas (NAP) es un indicador que va a medir el grado en el cual los
integrantes del proyecto captaron y aprendieron los conocimientos impartidos durante la
capacitación. El mismo se calcula de la siguiente manera:
NAP = PAP / PC, donde:
PAP: Total de personas que aprobaron las pruebas.
PC: Total de personas capacitadas.
Un valor igual o bastante cercano a uno para este indicador sería lo ideal.
Capítulo III
Capítulo III
Aprovechamiento del tiempo real de capacitación
Los horarios y las fechas para los cuales se planifiquen los cursos de capacitación que les son
impartidos a los integrantes del proyecto deben de cumplirse cabalmente, ya que esto podría traer
consigo que se atrasen o no se puedan ejecutar otras tareas.
El valor ideal de este indicador está dado de la siguiente manera:
FP => FI, donde:
FP: Fecha y hora en la que se planificó que se impartiera el curso.
FI: Fecha y hora real en la que se impartió el curso.
Siempre que el FP sea igual o mayor a FI significará que se está cumplimiento o sobre-cumpliendo
con el horario que se planificó que se impartiera determinado curso de capacitación, un valor distinto
a esto implicaría tomar las medidas necesarias para que esto no vuelva a suceder.
Captura de Requisitos
Otras de las áreas dentro del Proceso de Desarrollo de Software que requiere la necesidad de medir
y controlar es la captura de requisitos. La correcta gestión de esta área contribuye en gran medida al
éxito de los proyectos de Software, aportando el entendimiento y la comprensión de los problemas
que se necesitan solucionar y como resolverlos.
Entendimiento de los requisitos
En una especificación de requisitos es de vital importancia que los desarrolladores y miembros del
equipo sean capaces de entender el significado de los requisitos, o sea, que no exista ambigüedad o
lo que es lo mismo, que cada requisito tenga una sola interpretación, por lo que el lenguaje usado en
su definición no debe causar confusiones al lector.
El entendimiento de los requisitos (ER) se calcula mediante la fórmula:
ER= ((RT - RA) / RT) * 100, donde:
RA: Requisitos ambiguos.
RT: Requisitos totales.
Capítulo III
Capítulo III
Mientras el valor de ER se acerque al 100% será mejor, pues significará que no ha habido
ambigüedad en los requisitos.
Con este indicador los proyectos de la Facultad Tres podrán guardar registros del número de
requisitos ambiguos con respecto al total en una determinada revisión técnica formal, y compararla
con la anterior, de manera que se indique el avance o retroceso en el entendimiento de los requisitos
y por lo tanto, se tenga una idea de cómo ha sido el proceso de especificación y el entendimiento
con el cliente.
Estabilidad de los requisitos
Los requerimientos son la manera de comprender mejor el desarrollo de las necesidades de los
usuarios, los objetivos de la organización, el entorno de trabajo, entre otros factores, por lo cual es
esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y
utilizado.
Muchos son los cambios que pueden sufrir los requisitos a lo largo de todo el ciclo de vida del
Software incluyendo la eliminación, inserción y modificación. Es de vital importancia establecer con
qué frecuencia se analizará este indicador en cada proyecto. Teniendo en cuenta que en cada
iteración del sistema pueden surgir nuevos requisitos, si se aplica este indicador con una frecuencia
quincenal, los requisitos insertados se referirán a los que surgieron después de haber quedado
aprobados los requisitos iniciales para esa iteración, si se está comparando con una iteración
anterior entonces no se tendrán en cuenta los insertados.
Es muy importante lograr estabilidad, pues los continuos cambios en la especificación de los
requisitos traen consigo un atraso en el cronograma de trabajo, lo que puede ocasionar el
incumplimiento del plazo de entrega pactado con el cliente. También puede afectar los costes y variar
la cantidad de trabajo que ha de desarrollarse respecto a lo planificado.
Para tener una medida de cuan estable son los requisitos de un sistema se propone el indicador:
Estabilidad de los Requisitos (ETR), el mismo se calcula como:
ETR= ((RT - RC) / RT) * 100, donde:
RT: Requisitos totales.
RC: Requisitos cambiados (Sumatoria de los requisitos Insertados, Modificados y Eliminados).
Capítulo III
Capítulo III
Mientras el valor de ETR se acerque al 100% será mejor, pues mostrará que no se están aplicando
más cambios de requerimientos y que la definición de estos es estable.
Con este indicador los proyectos de la Facultad Tres podrán tener una idea del nivel de madurez
alcanzado durante el proceso de entrevista con el cliente y el levantamiento de los requerimientos,
pues mientras mejor haya sido este proceso menos cambios serán necesarios realizar en el
transcurso del proyecto.
Tiempo invertido en el proceso de análisis de requisitos
Para el análisis de requisitos es necesario disponer de cierto tiempo, el indicador que se propone a
continuación tiene como objetivo analizar el tiempo invertido para cada requisito específico.
El tiempo invertido en el proceso de análisis de requisitos (TAR) se calcula como:
TAR =TT / RT, donde:
TT: Tiempo total destinado al análisis de los requisitos.
RT: Requisitos totales.
Es importante tener una idea de cuanto tiempo puede demorar una correcta especificación de un
requisito, pues así puede estimarse el tiempo de análisis de requisitos para futuros proyectos que
tengan una complejidad similar. Esta estimación tal vez no sea muy precisa debido a que no se
puede conocer exactamente el tiempo que se demorará la especificación de requisitos, pues nunca
se sabe cuál será el último incluido (esto depende en gran medida de los continuos cambios
solicitados por el cliente) sin embargo, puede establecerse la comparación entre proyectos que
tengan objetivos similares a partir de la información inicial que se tenga de los mismos. Esta medida
contribuye a la optimización del tiempo.
Gestión de Riesgos
Otra de las áreas de gran importancia en el Proceso de Desarrollo de Software es la gestión de
riesgos, en la que pueden identificarse tempranamente los posibles riesgos y tomar medidas
correctivas para mitigarlos a tiempo, estos deben tenerse en cuenta para decidir si se continúa con el
proyecto o no.
Esta es una de las actividades que se inicia en la primera etapa de un proyecto y se desarrolla a lo
largo de todo su ciclo de vida llegando finalmente hasta la aceptación del producto obtenido.
Capítulo III
Capítulo III
El tiempo invertido identificando, analizando y gestionando los riesgos merece la pena por muchas
razones: menos trastornos durante el proyecto; una mayor habilidad de seguir y controlar el
proyecto; y la confianza que da planificar los problemas antes que ocurran.
Medición de la identificación de los riesgos
Para la identificación de los riesgos en los proyectos productivos de la Facultad Tres se propone
hacer una medición que guarde los riesgos más comunes en cada una de las etapas del desarrollo
del Software así como las consecuencias que traen consigo cada uno de ellos: (el incremento de los
costos, la cancelación del proyecto, la insatisfacción del cliente, entre otras), de manera tal que al
cabo de cierto tiempo, guardando estos registros históricos al comenzar un nuevo proyecto, se
tengan identificados los posibles riesgos y prevenirlos, valorando además su repercusión en cuanto
al alcance (cuánto se afecta) y la duración (por cuánto tiempo se manifiesta).
Deben guardarse además aquellas incidencias que hayan ocurrido, aun sin ser identificadas en las
primeras etapas, y que constituyen posibles riesgos para proyectos futuros.
Probabilidad de que ocurran riesgos de un mismo tipo
Los riesgos pueden ser de tipo personal, organizativos, de herramientas, de requerimientos, de
estimación, de presupuesto, etcétera.
La probabilidad de ocurrencia de riesgos de un tipo determinado (PR) está dada por la siguiente
ecuación:
PR = CRT / TTR, donde:
CRT: Número de veces que ocurre un riesgo de un determinado tipo durante el desarrollo del
proyecto.
TTR: Número total de riesgos que ocurrieron (hayan sido o no identificados).
Realizando este cálculo se puede ordenar por probabilidad de ocurrencia los riesgos más frecuentes
en el desarrollo de cualquier proyecto y así teniendo en cuenta el orden de prioridad mitigarlos y
contrarrestar los efectos que puedan ocasionar al sistema. Estos datos también serán útiles para los
próximos análisis de riesgos.
Capítulo III
Capítulo III
Efectividad de la mitigación de riesgos
El plan de mitigación de los riesgos tiene definidas todas las acciones necesarias para reducir o
eliminar los riesgos. El objetivo del siguiente indicador es determinar la relación existente entre los
riesgos mitigados y el total de riesgos identificados.
La efectividad de la mitigación de riesgos (RM%) está dada por la siguiente ecuación:
RM% = (RM / RI) * 100, donde:
RM: Riesgos Mitigados.
RI: Riesgos Identificados.
A medida que el porciento de mitigación de riesgos se acerque al 100%, significará que el número de
riesgos mitigados se acerca a los identificados, o sea, se habrán empleado mejores métodos para
contrarrestar estos riesgos.
Guardando estos datos podrá conocerse cuán efectivos han sido los planes de mitigación de riesgo,
se tendrá un conocimiento de las soluciones que fueron efectivas y por lo tanto pueden ser usadas
nuevamente para mitigar riesgos similares a los resueltos. Además en caso de que algún riesgo no
haya sido mitigado o identificado será necesario realizar un plan de contingencia.
Capítulo III
Capítulo III
3.5.2 Esquema del Procedimiento Propuesto
Fig. 15 Estructura del Procedimiento Propuesto. Fuente: Elaboración Propia
Diagnóstico de la ejecución
de las áreas claves
Identificación de las variables
críticas por área clave
Identificación de las variables
críticas por área clave
Identificar las áreas críticas
Identificar las áreas críticas
Diseño del sistema de indicadores
por área crítica
Diseño del sistema de indicadores
por área crítica
Medición de los indicadores
Medición de los indicadores
Archivar datos
Archivar datos
Comparación y análisis con datos
históricos
Comparación y análisis con datos
históricos
Evaluación de cada área
Evaluación de cada área
Puesta en marcha de acciones
correctivas
Puesta en marcha de acciones
correctivas
Control de Gestión
Actualización del expediente
de proyecto
Actualización del expediente
de proyecto
Toma de decisiones
Toma de decisiones
Seguimiento y
control
Seguimiento y
control
Herramienta
de apoyo a la
gestión
Herramienta
de apoyo a la
gestión
Capítulo III
Capítulo III
3.5.3 Descripción del Procedimiento
Diagnóstico de la ejecución de las áreas claves
La realización de un diagnóstico como elemento de entrada al siguiente procedimiento garantiza el
aseguramiento del nivel de partida. El mismo permite obtener en cada una de las áreas claves
definidas en la tabla 5, cuáles son los elementos que limitan la ejecución de las mismas. El proceso
diagnóstico debe realizarse en función de las variables definidas por área en dicha tabla, para
caracterizar cada una de las áreas en función de ellas. Estas acciones deben estar dirigidas a
responder la siguiente pregunta: ¿Qué elementos están afectando?
Identificación de las variables críticas por área clave
Después de haberse diagnosticado el funcionamiento de las áreas que se quieren controlar, se
obtienen las variables que limitan el desarrollo de las mismas. Se consideran variables críticas todas
aquellas que afecten de una forma u otra en la ejecución de cada una de las áreas. Estas acciones
deben estar dirigidas a responder la siguiente pregunta: ¿Sobre qué se debe accionar?
Identificar las áreas críticas
La identificación de las áreas críticas depende de la identificación de variables críticas dentro de
ellas que afectan su ejecución. Permitiendo determinar cuáles son aquellas áreas dentro del proceso
sobre las que se debe trabajar. Estas acciones deben estar dirigidas a responder la siguiente
pregunta: ¿Dónde se debe accionar?
Diseño del sistema de indicadores por área crítica
Después de haberse identificado las áreas claves a trabajar y dentro de ellas las variables que
limitan el desarrollo de las mismas, se debe precisar un sistema de indicadores para medir el
funcionamiento de ellas. Los cuales deben girar entorno a los ya definidos en la tabla 5 para medir
cada una de las variables en las áreas. Estas acciones deben estar dirigidas a responder la
siguiente pregunta: ¿Con qué medir?
Medición de los indicadores
Una vez identificado el sistema de indicadores a medir sobre las variables por área crítica en un
momento dado del sistema de control, se procede a la ejecución del proceso de medición. Este
proceso debe permitir observar el valor cuantitativo o cualitativo de cada una de ellas. Estas
Capítulo III
Capítulo III
acciones deben estar dirigidas a responder la siguiente pregunta: ¿En qué estado se encuentran las
variables?
-Archivar datos
Del sistema de indicadores definidos por cada una de las áreas se debe registrar toda la
información referente a cada uno de ellos en la tabla “Documentar Indicadores” (ver anexo 4). De
manera que queden plasmadas las evidencias de los resultados obtenidos durante el proceso de
medición en cada iteración.
-Comparación y análisis con datos históricos
Después de haber obtenido el resultado en la medición a través de los indicadores, se podrán
hacer comparaciones con datos históricos de otras iteraciones, y observar las tendencias de las
variables. Estas permitirán caracterizar y dar seguimiento a los resultados de las mismas.
Evaluación de cada área
Una vez que se tenga el valor de los indicadores por cada una de las áreas, y se realice la
comparación del mismo con datos históricos, se debe analizar si el funcionamiento de la misma es
satisfactorio o no. Este funcionamiento depende de las tendencias de cada una de las variables
medidas en la ejecución de las áreas. Estas acciones deben estar dirigidas a responder la siguiente
pregunta: ¿Cómo se encuentran las áreas?
Puesta en marcha de acciones correctivas
Después de tener la evaluación de cada una de las áreas, se deben tomar acciones correctivas
sobre aquellas variables con tendencias negativas. Estas acciones deben estar encaminadas a
revertir el estado en el que se encuentran con el objetivo de encaminar la gestión del Proceso de
Desarrollo. Estas acciones deben estar dirigidas a responder la siguiente pregunta: ¿Qué se debe
hacer?
Herramienta de apoyo seleccionada
Gestionar todo el Proceso de Desarrollo de un proyecto, incluyendo los recursos tanto humanos
como materiales de los que dispone el mismo, controlando sus tiempos de duración y sus
porcentajes de dedicación, es una labor compleja y prácticamente inabordable sin la ayuda de
determinadas herramientas que den soporte a esta tarea de planificación y Gestión de Proyectos.
Capítulo III
Capítulo III
Como parte del presente procedimiento se propone además la utilización de la herramienta
DotProject como un apoyo a la gestión de los proyectos productivos de la Facultad Tres.
Como la misma es basada en web, es multiusuario, e incluye módulos para compañías y para
proyectos, puede ser instalada en un servidor central en el área de dirección de producción de la
Facultad, y a partir de ahí todos los proyectos trabajen sobre ella, y como esta herramienta se perfila
para trabajar en entornos colaborativos, los integrantes de todos equipos de trabajo pueden trabajar
online compartiendo información relativa de los diferentes proyectos que existan. De esta forma se le
facilita a la dirección de producción de la Facultad tener un control del progreso de cada uno de sus
proyectos, llevar un seguimiento de los problemas relacionados a los mismos, ver el estado de
cumplimiento de sus cronogramas de trabajo, etcétera.
Salidas del procedimiento
El proceso anteriormente realizado, es el resultado del funcionamiento del Control de Gestión
aplicado a una organización. Después de haber tomado acciones correctivas con respecto a cada
una de las deficiencias detectadas por áreas, se deben tomar decisiones en función de las mejoras
continuas. En dependencia del grado de cada una de las decisiones a tomar, se debe consultar
jerárquicamente a las direcciones responsables en el funcionamiento del procedimiento, hasta llegar
a la dirección de producción de la Facultad Tres de la UCI.
Todo lo anteriormente determinado en cado uno de los pasos, constituyen elementos decisivos en la
organización. Por lo que se