Control de gestión de proyectos de software

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.

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 UCI[1] 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).

Responde esta encuesta sobre consumo de redes sociales. Nos ayudará a brindarte mejor información.

¿Usas sitios de redes sociales para encontrar información académica o laboral?*

¿Usas sitios de redes sociales para encontrar información académica o laboral?*

¿Qué sitios de redes sociales utilizas para investigación académica o laboral*

¿Qué sitios de redes sociales utilizas para investigación académica o laboral*

Puedes seleccionar las opciones que quieras.

Que tipo de dispositivo usas al utilizar redes sociales*

Que tipo de dispositivo usas al utilizar redes sociales*

¿Cuántas cuentas de redes sociales tienes?*

¿Cuántas cuentas de redes sociales tienes?*

¿Cuántas horas a la semana le dedicas a las redes sociales?*

¿Cuántas horas a la semana le dedicas a las redes sociales?*

Control de Gestión de los Proyectos de Software

Estructura de Producción de la Facultad Tres de la UCI

Fig. 1 Estructura de Producción de la Facultad Tres de la UCI

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.

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:

  • 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: 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.

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)

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).

Control de Gestión de los Proyectos de Software

Grupos de procesos de la Gestión de Proyectos. (PMI, 2004)

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.
  • 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 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).

Control de Gestión de los Proyectos de Software

El proceso de Software. (Pressman, 2000)

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.

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.

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)

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)

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, exige técnicas 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:

“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 té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.

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.

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 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.
  • 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.
  • 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ándares[2]; 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.

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?
  • ¿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

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.

  • 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.

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.
  • 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.

[1] Universidad de las Ciencias Informáticas

[2] Pueden ser conceptualizados como la definición clara de un modelo, criterio, regla de medida. Señalan claramente el comportamiento esperado y deseado. Requieren ser establecidos con el fin de contar con una referencia que permita identificar las variaciones presentadas y aplicar las medidas correctivas necesarias.

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 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.
  • 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ón[1] 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).

Control de Gestión de los Proyectos de Software

Control de Gestión de los Proyectos de Software

Fig. 4 Nivel de concordancia con los aspectos del parte de producción

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.
Control de Gestión de los Proyectos de Software

Control de Gestión de los Proyectos de Software

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.
Control de Gestión de los Proyectos de Software

Control de Gestión de los Proyectos de Software

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.

Del análisis de este aspecto también queda definida la tercera área, como otra a ser controlada dentro del proceso: Pruebas de Calidad.

Control de Gestión de los Proyectos de Software

Control de Gestión de los Proyectos de Software

Fig. 7 Nivel de concordancia con el aspecto 19

  • 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.
Control de Proyectos de Software

Control de Proyectos de Software

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.

[1]Mecanismo con el cual contaba la Facultad Tres de la UCI para tener un control semanalmente del resultado del trabajo en sus proyectos productivos durante todo el Proceso de Desarrollo de Software.

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.

A partir de los resultados obtenidos de los elementos ya enumerados que miden de alguna forma atributos[1] 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:

[1] Cuando se habla de atributo se refiere a una determinada característica que se pretende medir y cuantificar (como puede ser la calidad, el tamaño, el tiempo, entre otras).

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.

Control de Proyectos de Software

Control de Proyectos de Software

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 Riesgos. 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.

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.

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

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

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

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, 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 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 a cabo 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.

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 Mb[1] 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, 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 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.
  • 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

Cantidad de proyectos de la Facultad Tres que la utilizan (expresado en porciento)

[1] Unidad de medida de cantidad de datos informáticos. 

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 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 estructurada 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:

  • 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.

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: 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.

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.

Jerarquía de responsabilidad en la ejecución del procedimiento

Jerarquía de responsabilidad en la ejecución del procedimiento

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 sí. (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 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.

Representación de las tareas respecto al tiempo

Representación de las tareas respecto al tiempo

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:

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)

Gráfico del esfuerzo del personal

Gráfico del esfuerzo del personal

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.

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.

Estado de los pedidos de cambio

Estado de los pedidos de cambio

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.

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

Gráfico de avance del rendimiento

Gráfico de avance del rendimiento

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.

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).

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:

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.

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

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.

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. 

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.

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).

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.

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.

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.

3.5.2 Esquema del Procedimiento Propuesto

Estructura del Procedimiento Propuesto

Estructura del Procedimiento Propuesto

Fig. 15 Estructura del Procedimiento Propuesto. Fuente: Elaboración Propia 

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

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 considera que cualquier cambio en cada una de las áreas debe quedar plasmado en el documento correspondiente al área dentro del Expediente de Proyecto. 

Seguimiento y control

Todo proceso de Control de Gestión en una organización se realimenta de un seguimiento a partir de la toma de decisiones en función de las mejoras continuas. El sistema de seguimiento se realiza al proceso que se está controlando totalmente, pero enfocado a la mejora de las acciones correctivas, y como conclusión del mismo se realiza el control de la iteración que entró una vez en seguimiento.

Este proceso de continuo control y seguimiento va a permitir detectar nuevas necesidades que vayan surgiendo en la entidad que se está controlando, así como eliminar determinada funcionalidad que no esté cumpliendo con el objetivo para el cual fue creada, esta realimentación va a permitir además ajustar y modificar el procedimiento propuesto inicialmente, proporcionando de esta forma una mejora continua en la gestión de todo el Proceso de Desarrollo del Software en cada uno de los proyectos de la Facultad Tres, en aras de encaminarlos hacia el logro de sus objetivos, que no son más que desarrollar productos Software de calidad, que satisfagan plenamente las demandas de sus clientes.

3.6 Conclusiones

Una vez concluido el presente capítulo se pueden declarar las siguientes conclusiones:

  • La descripción de un procedimiento enuncia cuál es el orden de los pasos a seguir en función del logro de objetivos. El diagrama describe la realización completa de las acciones a ejecutar.
  • El sistema de indicadores que se definieron por cada una de las áreas permitirán expresar el comportamiento y el desempeño de las mismas, y brindado esta información contribuirán a que se tomen acciones para mejorarlas.
  • La herramienta para gestionar y planificar los proyectos que se seleccionó como parte de la propuesta, es la que reúne dentro de todas las estudiadas, las funcionalidades que se necesitan para la correcta realización de dichas tareas y es la que más se adapta en estos momentos a las necesidades de la Facultad Tres.
  • Para la propuesta actual se definió su finalidad, sus responsables y sus límites de aplicación, posibilitando así su implantación y realización.

Conclusiones

Una vez finalizado el presente trabajo se pueden declarar las siguientes conclusiones:

  • La Gestión de Proyectos de Software constituye una rama de la ciencia Gestión de Proyectos en términos administrativos, los elementos teóricos que toma de la misma le permiten: convertirse en una actividad protectora del ciclo de vida de un software; manejar variables en el transcurso de la vida de un proyecto de software, a través de las cuales se miden las actividades del mismo con el fin de desarrollar el proceso de manera exitosa.
  • Un proceso de control forma parte de la Gestión de Proyecto en una organización permitiendo obtener: elementos específicos que intervienen en el desarrollo de la misma; 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; y proporciona información acerca de la situación de la ejecución de los planes.
  • Un sistema de indicadores se considera como un elemento vital para medir el desempeño de una organización, la función del mismo en cada una de las áreas ayudará a conocer el estado en el que se encuentran las mismas y de esta manera posibilitar que se tomen acciones para mejorarlas.
  • La propuesta del procedimiento para desarrollar un sistema de Control de Gestión para una organización llevó implícito: determinar las áreas claves dentro del proceso a controlar y las variables de gestión para operar sobre las áreas; los indicadores para medir cada una de las variables en las áreas; una base documental que permita obtener el historial de cada iteración del control; y una herramienta informática que le de soporte a todo el proceso. 

Recomendaciones

  • Continuar profundizando el estudio del tema, para definir un sistema de control que incluya nuevas áreas e indicadores por cada una de ellas, en aras de obtener el funcionamiento óptimo de procedimiento propuesto.
  • Teniendo en cuenta la novedad de los aportes teóricos de la investigación, se recomienda publicar un artículo científico con los resultados de la misma.
  • Recomendar a la dirección de producción de la Facultad Tres de la UCI el análisis del procedimiento y la valoración de los resultados teóricos y prácticos del mismo para mejorar el funcionamiento del Control de Gestión de los proyectos en la Facultad.

Bibliografía Referenciada 

  • (Abad, 1997), Abad, Darío., Control de Gestión. Colombia: Interpared Editores, 1997.
  • (Amat, 1992), Amat, Joan Mª., Control de Gestión. Barcelona: Ediciones Gestión 2000 S.A., 1992. pág. 35.
  • (Bermejo, 1996), Bermejo, Patricio Jiménez., Control de Gestión. Santiago: Jurídica Conosur, 1996.
  • (Buchele, 1976), Buchele, Robert B., Diagnóstico de empresas en crecimiento. 2da Edición. Ed. Atlas SP, 1976.
  • (Chiavenatto, 2000), Chiavenatto, Idalberto., Administración: Proceso Administrativo. Tercera Edición, Colombia: Ed. McGraw-Hill, 2000. 9584101617.
  • (Ciget, 2005), Ciget, G.D.I.V.P.E., Glosario de términos. l.: Granma International, 2005.
  • (CSI, 1999), CSI Métrica 3., Gestión de Proyectos de Software.
  • (Delgado, 2007), Delgado, B. G., Control de Gestión de Software de la Facultad Tres de la UCI. Diagnóstico de la Situación Actual. Ciudad de la Habana, 2007.
  • (Farol, 1961), Farol, H., Administración industrial y general. El ateneo, Buenos Aires, 1961.
  • (Fernández, 2007), Fernández, Bari Domínguez., http://www.degerencia.com. [En línea] [Citado: 2 12, 2007.] http://www.degerencia.com/articulo/fundamentos_de_gestión_de_proyectos_efectiva/imp.
  • (Gido, 1999), Gido, J, et, al., “Administración exitosa de Proyectos”. Edita International Thomson Editores. Buenos Aires, 1999, pág. 109.
  • (Goldratt, 1992), Goldratt, E., El síndrome del pajar. ¿Cómo extraer información del océano de datos? Nuevo León, México: Castillo Monterrey, 1992.
  • (Horna, 2004), Horna, Arístides Alfredo Vara., http://www.aristidesvara.com. [En línea] 2004. [Citado: 5 25, 2008]
  • (Humphrey, 1995), Humphrey, Watts S., “A discipline for software engineering”. Addison-Wesley, 1995.
  • (Humphrey, 2000), Humphrey, Watts. S., Introducción al Proceso de Software de Equipo
  • (Humphrey, 2001), Humphrey, Watts. S., Introducción al Proceso Software Personal. Editorial Félix Varela. La Habana, 2001.
  • (Información, 2005), Información, C. T. Y. D. N. N. C. D. T. D. L. Norma Cubana, ISO/IEC 9126-1:2001, Ingeniería de Software-Calidad del Producto, Oficina Nacional de Normalización, 2005.
  • (Jaramillo, 2008), Jaramillo, Carlos Mario Pérez.
  • (Jordán, 1995), Jordán, H., Control de Gestión. l.: DEADE, Comisión Europea, 1995.
  • (Kerzner, 1995), Kerzner H., “Project Management. A Systems Approach to Planning, Scheduling, and Controlling”, 5th Edition. Ed. ITP / Van Nostrand Reinhold. 1995.
  • (León, 2005), León, Rolando Alfredo Hernández., Curso básico de Gestión de Proyectos. Universidad de las Ciencias Informáticas. Dirección de Investigaciones. Ciudad de la Habana: s.n., 2005. pág. 79.
  • (Lourdes, 2000), Lourdes I. Rodríguez Peña, S. E. V., Introducción a la dirección integrada de proyectos (DIP)-Project Management. Volumen 1, 2000.
  • (McGarry, 1998), McGarry J y Otros., “Practical Software Measurement: A Foundation for Objective Project Management Version 3.1a”. 1998.
  • (Meneses, 2001), Meneses, M., La industria de Software en Chile: La Calidad y Madurez del Proceso de Desarrollo de Software. Disponible en: http://www.p2pays.org/ref/18/17621.pdf. [En línea] 2001.
  • (Menguzzato y Renau, 1986), Menguzzato y Renau., Dirección estratégica de la empresa. Valencia, Ed. Euroed, 1986, p.374.
  • (Nogueira, 2002), Nogueira Rivera D., Modelo conceptual y herramientas de apoyo para potenciar el Control de Gestión en empresas cubanas”. 2002.
  • (PMI, 2004), , Guía de los Fundamentos de la Dirección de Proyectos (PMBOK® Guide). Estados Unidos: PMI, 2004. 193069973-5.
  • (Pressman, 2000), Pressman, Roger S., Ingeniería del Software. Un enfoque práctico. España: s.n., 2000.
  • (Robert, 1994), Robert C. Appleby., Modern Business Administration. Sexta Edición, 1994. 978-0273602828.
  • (Soleiro, 2006), Soleiro, D.J. L., Formación y Administración de proyectos de investigación y desarrollo.
  • (Stephen, 2000), Stephen H. Kan., “Metrics and Models in Software Quality Engineering”: Addison- Wesley. 2000.
  • (Terry, 1993), Terry, George R., Administración y control de oficinas (10a. reimp.), CECSA, México, 1993.

Bibliografía Consultada

  • Abad, Darío., Control de Gestión. Colombia: Interpared Editores, 1997.
  • Amat, Joan Mª., Control de Gestión. Barcelona: Ediciones Gestión 2000 S.A., 1992. pág. 35.
  • Bermejo, Patricio Jiménez., Control de Gestión. Santiago: Jurídica Conosur, 1996.
  • Buchele, Robert B., Diagnóstico de empresas en crecimiento. 2da Edición. Ed. Atlas SP, 1976.
  • Chiavenatto, Idalberto., Administración: Proceso Administrativo. Tercera Edición, Colombia: Ed. McGraw-Hill, 2000. 9584101617.
  • Ciget, G.D.I.V.P.E., Glosario de términos. l.: Granma International, 2005.
  • CSI Métrica 3., Gestión de Proyectos de Software.
  • Delgado, B. G., Control de Gestión de Software de la Facultad Tres de la UCI. Diagnóstico de la Situación Actual. Ciudad de la Habana, 2007.
  • Farías, Eduardo Bustos.,angelfire.com/ak5/bustosfarias/clase13_2.pdf. [En línea] [Citado: 10 29, 2007]
  • Farol, H., Administración industrial y general. El ateneo, Buenos Aires, 1961.
  • Fernández, Bari Domínguez., http://www.degerencia.com. [En línea] [Citado: 2 12, 2007.] http://www.degerencia.com/articulo/fundamentos_de_gestión_de_proyectos_efectiva/imp.
  • Gido, J, et, al., “Administración exitosa de Proyectos”. Edita International Thomson Editores. Buenos Aires, 1999, pág. 109.
  • Goldratt, E., El síndrome del pajar. ¿Cómo extraer información del océano de datos? Nuevo León, México: Castillo Monterrey, 1992.
  • Hinojosa, María Alejandra., https://www.gestiopolis.com/recursos/documentos/fulldocs/ger/diaggantaleja.htm. [En línea] [Citado: 11 5, 2007]
  • Horna, Arístides Alfredo Vara., http://www.aristidesvara.com. [En línea] 2004. [Citado: 5 25, 2008]
  • Humphrey, Watts S., “A discipline for software Engineering”. Addison-Wesley, 1995.
  • Humphrey, Watts. S., Introducción al Proceso de Software de Equipo
  • Humphrey, Watts. S., Introducción al Proceso Software Personal. Editorial Félix Varela. La Habana, 2001.
  • Información, C. T. Y. D. N. N. C. D. T. D. L. Norma Cubana, ISO/IEC 9126-1:2001, Ingeniería de Software-Calidad del Producto, Oficina Nacional de Normalización, 2005.
  • Jaramillo, Carlos Mario Pérez.
  • Jordán, H., Control de Gestión. l.: DEADE, Comisión Europea, 1995.
  • Kerzner H., “Project Management. A Systems Approach to Planning, Scheduling, and Controlling”, 5th Edition. Ed. ITP / Van Nostrand Reinhold. 1995.
  • León, Rolando Alfredo Hernández., Curso básico de Gestión de Proyectos. Universidad de las Ciencias Informáticas. Dirección de Investigaciones. Ciudad de la Habana: s.n., 2005. pág. 79.
  • León, Rolando Alfredo Hernández. EL PARADIGMA CUANTITATIVO DE LA INVESTIGACIÓN CIENTIFICA. Cuidad de la Habana: s.n., 2002. 959-16-0343-6.
  • Lourdes I. Rodríguez Peña, S. E. V., Introducción a la dirección integrada de proyectos (DIP)-Project Management. Volumen 1, 2000.
  • McGarry J y Otros., “Practical Software Measurement: A Foundation for Objective Project Management Version 3.1a”. 1998.
  • Meneses, M., La industria de Software en Chile: La Calidad y Madurez del Proceso de Desarrollo de Software. Disponible en: http://www.p2pays.org/ref/18/17621.pdf. [En línea] 2001.
  • Menguzzato y Renau., Dirección estratégica de la empresa. Valencia, Ed. Euroed, 1986, p.374.
  • Nogueira Rivera D., Modelo conceptual y herramientas de apoyo para potenciar el Control de Gestión en empresas cubanas”. 2002.
  • Guía de los Fundamentos de la Dirección de Proyectos (PMBOK® Guide). Estados Unidos: PMI, 2004. 193069973-5.
  • Pressman, Roger S., Ingeniería del Software. Un enfoque práctico. España: s.n., 2000.
  • Rivero, Henry., http://fundabit.me.gob.ve/documento/articulo110.pdf. [En línea] [Citado: 4 25, 2008]
  • Robert C. Appleby., Modern Business Administration. Sexta Edición, 1994. 978-0273602828.
  • Soleiro, D.J. L., Formación y Administración de proyectos de investigación y desarrollo.
  • Stephen H. Kan., “Metrics and Models in Software Quality Engineering”: Addison- Wesley. 2000.
  • Team, Abartia., http://www.abartiateam.com/dotproject.html. [En línea] [Citado: 1 20, 2008]
  • Terry, George R., Administración y control de oficinas (10a. reimp.), CECSA, México, 1993.
  • UCI, Comunidad., http://Softwarelibre.uci.cu/Usuarios/rfestrada/acerca-del-dotproject/?searchterm=dotproject. [En línea] [Citado: 1 18, 2008]

Cita esta página

Céspedes Vega Anisleydi. (2011, julio 25). Control de gestión de proyectos de software. Recuperado de https://www.gestiopolis.com/control-gestion-proyectos-software/
Céspedes Vega Anisleydi. "Control de gestión de proyectos de software". gestiopolis. 25 julio 2011. Web. <https://www.gestiopolis.com/control-gestion-proyectos-software/>.
Céspedes Vega Anisleydi. "Control de gestión de proyectos de software". gestiopolis. julio 25, 2011. Consultado el . https://www.gestiopolis.com/control-gestion-proyectos-software/.
Céspedes Vega Anisleydi. Control de gestión de proyectos de software [en línea]. <https://www.gestiopolis.com/control-gestion-proyectos-software/> [Citado el ].
Copiar

Escrito por:

Imagen del encabezado cortesía de br1dotcom en Flickr