ADR-1-ADPI-Cap04-Tiempos - Gonzálo de la Vega S

Vista previa del material en texto

UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
 
Lic. Fabiana María Riva Abril 2010 1 
 
 
 
 
CAPÍTULO 4: 
 
 
GESTIÓN DEL TIEMPO DE UN PROYECTO 
 
 
 
Objetivos principales de este capítulo: 
• A partir de la EDT presentada en los capítulos anteriores desarrollar la planificación de tareas y recursos necesarios para 
el posterior seguimiento del proyecto 
• Desarrollar gráficamente las relaciones entre actividades con el apoyo de Diagramas de Red y Diagramas Gantt 
• Estimar los recursos requeridos y la duración de actividades o tareas de los entregables definidos 
 
Bibliografía utilizada: 
• Planificación, Programación y control de Proyectos. James P.Lewis. Ed. Ediciones S. 
• Metodología Métrica Versión 3. Ministerio de Administraciones Públicas de España 
• Guía de los Fundamentos de la Dirección de Proyectos (PMBOK). Cuarta Edición. Project Management Institute. Año 
2009 Capítulo 6: Gestión del Tiempo del Proyecto 
• Control de Proyectos por CPM y PERT. Norberto Munier. Ediciones Economía y Empresa. 
• Administración de Proyectos. Ted Klastorin. Ed. Alfaomega. 
• Mejores Prácticas para la estimación de Proyectos de Software. Juan Carlos Restrepo Montoya – Jorge Iván Juarez 
Murillo. Escuela de Ingeniería. Departamento de Ingeniería de Sistemas. Universidad EAFIT. Medellín. Año 2007. 
• Estimación del Esfuerzo basada en Casos de Uso. Mario Peralta. Centro de Ingeniería del Software e Ingeniería del 
Conocimiento (CAPIS) Escuela de Posgrado. ITBA. Buenos Aires. Año 2005. 
• Principios para un método de estimación de proyectos de software basado en escenarios principales. José Ignacio Cao. 
ITBA. Buenos Aires. Año 2006 
 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
 
Lic. Fabiana María Riva Abril 2010 2 
 
ASPECTOS GENERALES DE LA GESTIÓN DEL TIEMPO .................................................................................................... 3 
MÉTODOS DE ESTIMACIÓN DE ESFUERZO ................................................................................................................. 4 
BASADAS EN MODELOS.................................................................................................................................... 4 
BASADAS EN JUICIOS DE EXPERTOS ..................................................................................................................... 4 
JUICIO DE EXPERTOS ESTRUCTURADO ............................................................................................................................ 4 
LISTA DE CHEQUEO .................................................................................................................................................... 5 
ESTRUCTURA DE DESGLOSE DE TRABAJO (EDT O WBS) ................................................................................................... 6 
JUICIO DE EXPERTOS GRUPAL – TÉCNICA DE DELPHI ........................................................................................................ 7 
ORIENTADAS AL APRENDIZAJE ............................................................................................................................ 8 
EL PROCESO DE PLANIFICACIÓN EN UN PROYECTO .................................................................................................... 9 
DEFINICIONES Y HERRAMIENTAS PARA LA PLANIFICACIÓN ........................................................................................ 9 
DIAGRAMA DE RED ........................................................................................................................................ 10 
MÉTODOS DE REDUCCIÓN DE LA DURACIÓN (SIN REDUCCIÓN DEL ALCANCE) ............................................................. 17 
CONTROL Y SEGUIMIENTO DEL PROYECTO ............................................................................................................. 18 
ESTIMACIÓN DE PROYECTOS DE SOFTWARE ............................................................................................................ 19 
FACTORES QUE INCIDEN EN LA ESTIMACIÓN DEL SOFTWARE ................................................................................... 21 
TAMAÑO ................................................................................................................................................................ 21 
DESECONOMÍAS DE ESCALA ....................................................................................................................................... 21 
TIPOS DE SOFTWARE ................................................................................................................................................ 21 
FACTORES DEL PERSONAL .......................................................................................................................................... 21 
LENGUAJE DE PROGRAMACIÓN ................................................................................................................................... 21 
TÉCNICAS DE ESTIMACIÓN PARA PROYECTOS DE SOFTWARE ....................................................................................... 22 
ESTIMACIÓN POR LÍNEAS DE CÓDIGO. EL MODELO COCOMO .............................................................................. 23 
ESTIMACIÓN POR PUNTOS DE FUNCIÓN. MÉTODO DE ALBRECHT. .......................................................................... 24 
IDENTIFICACIÓN DE LOS COMPONENTES ....................................................................................................................... 24 
CÁLCULO DE LOS PUNTOS FUNCIÓN NO AJUSTADOS ....................................................................................................... 26 
AJUSTE DE LOS PUNTOS FUNCIÓN ............................................................................................................................... 26 
CÁLCULO DEL TIEMPO EN DÍAS DE ESFUERZO ................................................................................................................. 30 
CONSIDERACIONES ................................................................................................................................................... 31 
OTROS MODELOS DE ESTIMACIÓN ACTUALES ...................................................................................................... 31 
PLANIFICACIÓN DE PROYECTOS DE SOFTWARE......................................................................................................... 32 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 3 
ASPECTOS GENERALES DE LA GESTIÓN DEL TIEMPO 
 
El control de un proyecto consiste en comparar dónde estamos con dónde se supone que deberíamos estar, y 
emprender acciones para corregir las posibles desviaciones con respecto al objetivo. Sólo podemos saber dónde deberíamos 
estar con referencia a un plan. Por tanto, en ausencia de un plan, el control es imposible. 
 
Una de las razones más frecuentes para la ausencia de planificación se resume en una afirmación “No tengo tiempo para 
planificar”. El problema está en que la gestión de crisis es un círculo vicioso: no tenemos tiempo para planificar porque 
estamos demasiado ocupados apagando incendios, pero tenemos muchos incendios porque no planificamos, y vuelta a 
empezar. Sólo hay una salida: empezar a elaborar planes. 
 
El objetivo de la planificación de proyectos debe ser siempre elaborar un plan que sea realista, de forma que los 
directivospuedan evaluar con exactitud la viabilidad del trabajo. 
 
Una vez realizado el desglose del alcance de un Proyecto la siguiente tarea será la estimación. 
 
Una estimación no es un hecho. Las estimaciones no son exactas. Se basan muchas veces en la experiencia del experto 
que realiza el cálculo y éste termina utilizando como estimación el tiempo medio que dicha actividad haya requerido en 
proyectos anteriores. Con esto se reduce el riesgo, no se elimina. 
 
El Director de Proyectos se basará en este juicio del experto pero deberá conocer la técnica que el mismo utiliza para 
realizar la estimación para relacionarla al personal con que cuenta para realizar las actividades del proyecto. Las estimaciones 
dependerán mucho de ello ya que el personal afectado con mayor experiencia probablemente realice el trabajo más rápido, 
pero no hay una correlación exacta entre experiencia y velocidad en la realización del trabajo. Hay que reducir el tiempo de 
que dispone una persona para trabajar en un proyecto teniendo en cuenta otros proyectos al que está afectado, reuniones, 
pausas y otras interrupciones. 
El Director de Proyectos, entonces: 
• Debe revisar las estimaciones como un todo 
• Debe ser lo suficientemente agresivo como para lograr valores competitivos 
• Debe incluir los recursos suficientes para asegurar que los compromisos sean completados 
• Debe asegurar que el alcance del Trabajo está totalmente cubierto sin duplicaciones ni faltantes 
• Debe asegurar que la utilización del personal es razonable 
• Debe documentar todas las hipótesis 
• Debe poder justificar los valores presentados porque debe poder resistir las presiones para hacer reducciones 
 
Para los proyectos de construcción existen manuales con tablas promedios que contienen las duraciones medias 
previstas para actividades típicas, junto con factores de ajuste para compensar la localización geográfica, las condiciones 
meteorológicas y otras variables. Por desgracia para otros proyectos no se cuenta con tablas de ningún tipo, por lo que hay 
que elaborar datos históricos llevando registros de los trabajos de proyectos anteriores. Este es quizá uno de los beneficios 
más importantes de una metodología estandarizada de proyectos. 
 
Al hablar de la estimación nos referimos a ¿estimar actividades o estimar el Proyecto en su totalidad? 
Debe quedar claro que estimar la duración de una tarea única es mucho más sencillo que estimar la duración de un 
proyecto, que se compone de una multitud de tareas. Esto no significa que no se realicen estimaciones de alto nivel. Para una 
estimación rápida se puede comparar el proyecto previsto con otro anterior introduciendo los ajustes necesarios para las 
diferencias más evidentes. Si se necesita mayor grado de exactitud, se puede desglosar el trabajo en incrementos o tareas 
menores, se estima cada uno de ellos y se combinan para obtener la estimación total del proyecto. 
 
La estimación no es única y no se realiza solo al inicio del Proyecto. En la medida que aumenta la información que 
contamos sobre un Proyecto podremos disminuir el rango de error en las estimaciones con la siguiente aproximación: 
• Orden de magnitud. De -25% a +75% 
• Conceptual. De -15% a +50% 
• Presupuesto. De -10% a +25% 
• Definitivo: de -5% a +10% 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 4 
MÉTODOS DE ESTIMACIÓN DE ESFUERZO 
 
Los métodos o técnicas de estimación de esfuerzo se pueden clasificar en las siguientes categorías: 
 
 
BASADAS EN MODELOS 
 
Poseen un modelo matemático como su punto clave, involucran un algoritmo que se deriva de las veces de estudio de 
casos puntuales de proyectos conocidos. También es conocida como estimación paramétrica. Puede basarse en datos 
históricos tomados de proyectos anteriores (ej. % de esfuerzo requerido sobre el total del proyecto de una tarea específica) o 
extraerse de los estándares de la industria específica del proyecto (por ejemplo para la industria de la construcción: 1 m2 de 
piso lleva 0,5 hs/hombre de actividad, o para la industria del software el tamaño por líneas de código). 
 
 
BASADAS EN JUICIOS DE EXPERTOS 
 
Son útiles cuando no se poseen datos cuantificados. Capturan el conocimiento y la experiencia de las personas con 
amplio dominio en el área de interés, las cuales proveen estimaciones basadas en la síntesis de los eventos conocidos en 
proyectos anteriores, con los cuales el experto ha estado asociado o ha participado directamente. Algunas técnicas han sido 
desarrolladas para capturar el juicio de expertos, pero también toman medidas para mitigar la posibilidad de que el juicio de 
un solo experto afecte al resultado final. Estas técnicas se conocen como: Juicio de experto individual, Técnica de Delphi, 
WBS. 
 
JUICIO DE EXPERTOS ESTRUCTURADO 
 
El juicio de experto individual no tiene por qué ser informal e intuitivo, pueden utilizarse procedimientos definidos 
para que los expertos se basen en ellos y tener mayor control de lo estimado. 
 
El uso de rangos para la estimación de cada tarea como el modelo PERT permite al estimador ponerse en tres 
situaciones: Más Probable, Optimista y Pesimista. 
 
Más probable: cuando todo el ambiente se desenvuelve normalmente. Esta es la estimación que por defecto usan los 
estimadores 
Optimista: Cuando todo sale mejor de lo esperado 
Pesimista: Cuando todo sale mal y se generan problemas en la ejecución de la tarea. Una de las circunstancias para 
que suceda esto es que los riesgos planteados para el proyecto se materialicen. 
 
 
Estimación (µ): Pesimista + 4 x Más Probable + Optimista 
 6 
Desviación estándar (σ): Pesimista – Optimista 
 6 
 
Basándonos en este método se puede disminuir el riesgo de una mala estimación recurriendo al manejo de 
probabilidades que nos brinda este método asociado a la Curva de Distribución Normal: 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 5 
µ= media Valores
Cantidad de 
Ocurrencias
El area bajo la curva indica el % de 
probabilidad. σ (sigma) = desviación 
estándar 
68%
95%
50%
-1σ -2σ -3σ -4σ +1σ +2σ +3σ +4σ 
84% 
 
Por ejemplo, si consideramos los valores de duración de una tarea: 
Pesimista = 40 
Más Probable = 20 
Optimista = 15 
 
La Estimación µ = 40 + 4 x 20 + 15 = 23 
 6 
La desviación estándar σ = 40 – 15 = 4 
 6 
Por lo tanto, la estimación de duración de la tarea en valores menores o iguales a 23 tendrá un 50% de probabilidad. Si 
quisiéramos aumentar la probabilidad a un 84% deberíamos considerar el valor 27 (23 + 4). Si consideráramos el rango de 
duración entre 19 y 27 la probabilidad será de 68%. 
 
Este método le permite al Director de Proyecto manejar un “colchón” en la duración de las tareas estimadas para 
reducir el riesgo de las estimaciones erróneas. 
 
 
LISTA DE CHEQUEO 
 
Como ocasionalmente los estimadores suelen omitir ciertas consideraciones a la hora de realizar estimaciones, es 
bueno contar con una lista de chequeo para evitar estas omisiones. Un ejemplo de lista de chequeo podría ser: 
 
1. ¿Lo que está siendo estimado está claramente definido? 
2. ¿La estimación incluye todos los tipos de trabajo necesarios para completar la tarea? 
3. ¿La estimación incluye todas las áreas funcionales necesarias para completar la tarea? 
4. ¿La estimación está descompuesta en un nivel de detalle que permita descubrir tareas escondidas? 
5. ¿Se tomaron en cuenta hechos documentados de proyectos anteriores en lugar de estimar en base a 
recuerdos? 
6. ¿La estimación fue aprobada por la persona querealizará el trabajo? 
7. ¿Se asume en la estimación que la productividad será similar a la alcanzada en asignaciones similares? 
8. ¿La estimación incluye casos optimistas, pesimistas y probables? 
9. ¿Los casos pesimistas son en realidad el peor de los casos? 
10. ¿Los supuestos en que se basó la estimación fueron documentados? 
11. ¿Ha cambiado la situación desde que la estimación fue planteada? 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 6 
ESTRUCTURA DE DESGLOSE DE TRABAJO (EDT O WBS) 
 
En el capítulo anterior hemos tratado el tema de Definición del Alcance y trabajado la herramienta EDT o WBS para 
lograr definir en forma completa los requerimientos del Proyecto. El esquema de una EDT puede ser el siguiente: 
 
 
La EDT es una forma de organizar los elementos de un proyecto en una jerarquía. 
Además de mejorar la definición del alcance, esta estructura simplifica la tarea de estimar y luego controlar el proyecto. 
Probablemente al definir el baseline de Alcance no nos hemos detenido a analizar más que aquellos entregables que 
constituían los principales objetivos del proyecto. Antes de continuar con la especificación de tiempos debemos corroborar 
que se hayan definido absolutamente todas las actividades que componen el Proyecto en cuestión. 
 
Al utilizar la EDT para la estimación de duración de actividades y recursos se debe: 
• Verificar la correcta descomposición para ver si los niveles inferiores son necesarios y suficientes para la terminación 
del ítem (Proyecto, Subproyecto, entregable y actividad) descompuesto y para ver si cada ítem está claramente 
definido. 
• Identificar todas las tareas a realizar y los recursos asignados a ellas que incluye la identificación además de las 
actividades auxiliares o de soporte (en Administración de Proyectos estas actividades son denominadas: level-of-
effort. Por ejemplo: contabilizar los gastos del proyecto, comunicación con los clientes, compra de insumos 
generales del proyecto, etc.). 
• La identificación de los entregables en términos de resultados tangibles y verificables deben incluir aquellas tareas 
que correspondan a la verificación. 
• Realizar estimaciones sobre duración de las tareas 
• Utilizar la duración de las tareas en la elaboración de un cronograma de trabajo para el proyecto. 
• Asignar responsabilidades para cada uno de los ítems 
• Agregar todas las acciones definidas en el Plan de Riesgos 
• Incluir todas las actividades vinculadas al Plan de Calidad (del producto y del proyecto), definiciones de estándares y 
procedimientos a aplicar 
• Incluir Planes de Capacitación y actividades de “Team Building” 
y 
• Documentar todos los supuestos que se consideren durante la realización del plan 
 
Un beneficio adicional de la EDT es que proporciona una representación visual del alcance total del proyecto utilizando 
un diagrama jerárquico al que se le agregan la duración, los recursos y los costos asociados (que veremos en el Capítulo 05: 
Gestión de Costos). 
Las organizaciones que realizan proyectos muy grandes pueden ampliar la estructura vista como ejemplo en la página 
anterior, pero una regla empírica es que no se deben utilizar más de 20 niveles. 
PROYECTO 
SUBPROYECTO 1 
SUBPROYECTO 2 
SUBPROYECTO n 
ENTREGABLE 2/1 
ENTREGABLE 2/2 
ENTREGABLE 2/3 
ENTREGABLE 2/m 
ACTIVIDAD 1 
ACTIVIDAD 2 
ACTIVIDAD k 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 7 
JUICIO DE EXPERTOS GRUPAL – TÉCNICA DE DELPHI 
 
Su nombre se inspira en el antiguo oráculo de Delphos y fue utilizado inicialmente a comienzos de los años 50 en el 
Centro de Investigación estadounidense RAND Corporation. 
 
Linstone y Turoff (1975) definen: 
"El Delphi puede ser caracterizado como un método para estructurar el proceso de comunicación grupal, de modo que 
ésta sea efectiva para permitir a un grupo del individuos, como un todo, tratar con problemas complejos". 
 
Un Delphi consiste en la selección de un grupo de expertos a los que se les pregunta su opinión sobre cuestiones 
referidas a acontecimientos del futuro. Las estimaciones de los expertos se realizan en sucesivas rondas, anónimas, al objeto 
de tratar de conseguir consenso, pero con la máxima autonomía por parte de los participantes. 
Por lo tanto, la capacidad de predicción de Delphi se basa en la utilización sistemática de un juicio intuitivo emitido por 
un grupo de expertos. Es decir, el método Delphi procede por medio de la interrogación a expertos con la ayuda de 
cuestionarios sucesivos, a fin de poner de manifiesto convergencias de opiniones y deducir eventuales consensos. 
 
Este método presenta tres características fundamentales: 
• Anonimato: Durante un Delphi, ningún experto conoce la identidad de los otros que componen el grupo de debate. 
Esto tiene una serie de aspectos positivos, como son: 
o Impide la posibilidad de que un miembro del grupo sea influenciado por la reputación de otro de los 
miembros o por el peso que supone oponerse a la mayoría. La única influencia posible es la de la 
congruencia de los argumentos. 
o Permite que un miembro pueda cambiar sus opiniones sin que eso suponga una pérdida de imagen. 
o El experto puede defender sus argumentos con la tranquilidad que da saber que en caso de que sean 
erróneos, su equivocación no va a ser conocida por los otros expertos. 
• Iteración y realimentación controlada: La iteración se consigue al presentar varias veces el mismo cuestionario. 
Como, además, se van presentando los resultados obtenidos con los cuestionarios anteriores, se consigue que los 
expertos vayan conociendo los distintos puntos de vista y puedan ir modificando su opinión si los argumentos 
presentados les parecen más apropiados que los suyos. 
• Respuesta del grupo en forma estadística: La información que se presenta a los expertos no es sólo el punto de 
vista de la mayoría, sino que se presentan todas las opiniones indicando el grado de acuerdo que se ha obtenido. 
 
En la realización de un Delphi aparece una terminología específica: 
 
Circulación: Es cada uno de los sucesivos cuestionarios que se presenta al grupo de expertos. 
Cuestionario: El cuestionario es el documento que se envía a los expertos. No es sólo un documento que contiene una 
lista de preguntas, sino que es el documento con el que se consigue que los expertos interactúen, ya que 
en él se presentarán los resultados de anteriores circulaciones. 
Panel: Es el conjunto de expertos que toma parte en el Delphi. 
Moderador: Es la persona responsable de recoger las respuestas del panel y preparar los cuestionarios. 
 
Antes de iniciar un Delphi se realizan una serie de tareas previas, como son: 
• Delimitar el contexto y el horizonte temporal en el que se desea realizar la previsión sobre el tema en estudio. 
• Seleccionar el panel de expertos y conseguir su compromiso de colaboración. Las personas que sean elegidas no 
sólo deben ser grandes conocedores del tema sobre el que se realiza el estudio, sino que deben presentar una 
pluralidad en sus planteamientos. Esta pluralidad debe evitar la aparición de sesgos en la información disponible en 
el panel. 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 8 
• Explicar a los expertos en qué consiste el método. Con esto se pretende conseguir la obtención de previsionesfiables, pues los expertos van a conocer en todo momento cuál es el objetivo de la cada una de los procesos que 
requiere la metodología. 
 
Un Delphi consta básicamente de 4 fases: 
 
1. La primera fase se caracteriza por la exploración del tema en discusión. Cada individuo contribuye con la 
información adicional que considera pertinente. 
El primer cuestionario es desestructurado, no existe un guión prefijado, sino que se pide a los expertos que 
establezcan cuáles son los eventos y tendencias más importantes que van a suceder en el futuro referentes al área 
en estudio. 
Cuando los cuestionarios son devueltos, éste realiza una labor de síntesis y selección, obteniéndose un conjunto 
manejable de eventos, en el que cada uno está definido de la forma más clara posible. Este conjunto formará el 
cuestionario de la segunda circulación. 
2. La segunda fase comprende el proceso en el cual el grupo logra una comprensión del tema. Salen a la luz los 
acuerdos y desacuerdos que existen entre los participantes con respecto al tema. 
Los expertos reciben el cuestionario con los eventos sintetizados en la etapa anterior. Una vez contestados los 
cuestionarios son devueltos al moderador, que realiza un análisis estadístico de las previsiones de cada evento. El 
análisis se centra en el cálculo de la mediana (50% de los expertos), el primer cuartil o cuartil inferior (en el que se 
produce lo mismo para el 25% de los expertos) y tercer cuartil o cuartil superior (para el 75%). 
El moderador confecciona el cuestionario de la tercera circulación que comprende la lista de eventos y los 
estadísticos calculados para cada evento. 
3. La tercera fase explora los desacuerdos, se extraen las razones de las diferencias y se hace una evaluación de ellas. 
Los expertos reciben el tercer cuestionario y se les solicita que realicen nuevas previsiones. Si se reafirman en su 
previsión anterior y ésta queda fuera de los márgenes entre los cuartiles inferior y superior, deben dar una 
explicación del motivo por el que creen que su previsión es correcta y la del resto del panel no. Estos argumentos se 
realimentarán al panel en la siguiente circulación. Al ser estos comentarios anónimos, los expertos pueden 
expresarse con total libertad, no estando sometidos a los problemas que aparecen en las reuniones cara a cara. 
Cuando el moderador recibe las respuestas, realiza de nuevo el análisis estadístico y, además, organiza los 
argumentos dados por los expertos cuyas previsiones se salen de los márgenes intercuartiles. El cuestionario de la 
cuarta circulación va a contener el análisis estadístico y el resumen de los argumentos. 
4. La cuarta fase es la evaluación final. Esto ocurre cuando toda la información previamente reunida ha sido analizada 
y los resultados obtenidos han sido enviados como retroalimentación para nuevas consideraciones. 
 
Se solicita a los expertos que hagan nuevas previsiones, teniendo en cuenta las explicaciones dadas por los expertos. 
Se pide a todos los expertos que den su opinión en relación con las discrepancias que han surgido en el cuestionario. 
Cuando el moderador recibe los cuestionarios, realiza un nuevo análisis y sintetiza los argumentos utilizados por los 
expertos. 
Teóricamente, ya habría terminado el Delphi, quedando tan sólo la elaboración de un informe en el que se 
indicarían los resultados a partir del análisis de las respuestas de los expertos y los comentarios realizados por los 
panelistas. Sin embargo, si no se hubiese llegado a un consenso, existiendo posturas muy distantes, el moderador 
debería confrontar los distintos argumentos para averiguar si se ha cometido algún error en el proceso. 
 
 
 
ORIENTADAS AL APRENDIZAJE 
 
Los métodos de estimación de esta categoría van desde las estimaciones que se realizan manualmente por analogía con 
un proyecto similar anterior hasta las que utilizan redes neuronales. 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 9 
EL PROCESO DE PLANIFICACIÓN EN UN PROYECTO 
 
Se pueden utilizar las técnicas o métodos vistos anteriormente en un proceso que contemple distintas etapas en la 
planificación considerándolo así un Método de Ingeniería. Las etapas de este proceso podrían ser: 
 
1. Seguir las reglas para la elaboración del EDT 
2. Secuenciar las actividades y establecer las dependencias (Diagrama de Red) 
3. Estimar el esfuerzo (personas y tiempo) para cada actividad utilizando técnicas de expertos o técnicas 
basadas en modelos 
4. Nivelar los recursos 
5. Determinar el esfuerzo total por tipo de recurso 
6. Identificar el camino crítico y determinar la duración 
7. Revisar – Iterar – Obtener acuerdos 
 
Si el costo es la variable de ajuste podría pensarse un Método que limite el alcance del trabajo al presupuesto (diseño al 
costo). 
1. Determinar el objetivo de costo 
2. Identificar y priorizar las funcionalidades 
3. Determinar el costo de cada una 
4. Eliminar (o agregar) funciones 
5. Determinar nuevo total 
6. Revisar – Iterar - Obtener acuerdo 
 
Las funciones y capacidades a ser provistas deben ser revisadas con el cliente para asegurar sus expectativas y 
entendimiento 
 
 
 
DEFINICIONES Y HERRAMIENTAS PARA LA PLANIFICACIÓN 
 
Entregable (work product/package) será el resultado final de un grupo de actividades 
Trabajo: actividad productiva continua para lograr un objetivo. Tiene un comienzo, fin y duración definidos 
Esfuerzo: cantidad de trabajo medible (tiempo/persona) requerido para completar una actividad 
Duración: cantidad de tiempo para completar una actividad 
Tiempo transcurrido: Duración de la actividad independiente de los días laborales � 24 hs. = 1 día 
Tiempo de trabajo: Duración de la actividad basada en la cantidad de días laborales � 24 hs. = 3 días 
Disponibilidad: % de tiempo dedicado del recurso asignado 
Productividad: % de efectividad del recurso (a mayor efectividad menor tiempo) 
Costo de la Actividad = Esfuerzo x costo de unidad de esfuerzo 
 Productividad 
Duración de la actividad = Duración del esfuerzo / Productividad 
 Disponibilidad 
Secuenciamiento de las actividades: El proceso que consiste en definir la precedencia de cada una de las actividades 
(actividades anteriores o predecesoras y actividades siguientes en la relación o sucesoras) verificando que no existan lazos ni 
redundancias y que las relaciones establecidas sean realmente las correctas. 
 
La secuencia de actividades puede ser afectada por: 
• Descripción del Producto (Ej: deben haberse definido los requerimientos antes de comenzar el diseño del 
producto) 
• Precedencias obligatorias (Ej: debe haberse decidido el lenguaje antes de comenzar la codificación) 
• Precedencias discrecionales (orden) (Ej: primero debe realizarse la entrevista con el jefe del sector para luego 
realizar la entrevista a los usuarios). 
• Precedencias externas. (Ej: el subcontratista debe haber establecido su plan de trabajo antes de que pueda 
establecerse la inclusión del mismo en el plan general del proyecto) 
• Restricciones (Ej: el proyecto B comenzará sólo si se ha finalizado el proyecto A) 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 10 
• Supuestos (Ej: se considera que la estimación de esta tarea está sujeta a la disponibilidad del 100% de las personas 
afectadas a la misma) 
 
La relación establecida entre las actividades puede ser: 
• Final a Inicio: La actividad A debe finalizar antes que la B pueda comenzar 
• Final a Final: La actividad A debe finalizar antes o al mismo tiempo que la B pueda finalizar 
• Inicioa Inicio: La actividad A debe comenzar antes que la B pueda comenzar 
• Inicio a Final: La actividad B debe comenzar antes que la A pueda finalizar 
 
Las actividades pueden comenzar: 
ASAP (as soon as possible): deben comenzar tan pronto como sea posible 
ALAP (as late as possible): deben comenzar tan tarde como sea posible 
 
 
DIAGRAMA DE RED 
 
El Diagrama de Red esquematiza las relaciones lógicas de las actividades de un proyecto con sus duraciones y su 
secuencia. Los métodos de diagramación más comunes son: 
• Diagramación por Precedencias: actividades representadas en cuadros (nodos) y conectadas por flechas AON 
(Activity on node) 
• Diagramación con flechas: actividades representadas por flechas y conectadas por puntos (nodos) AON (Activity 
on arrow). Usa solo final a inicio y puede requerir tareas sin duración (dummy) para permitir el control 
 
 
Una vez estimadas las duraciones de todas las actividades o tareas y secuenciadas las mismas realizaremos el gráfico 
de la red para representar el Proyecto. 
 
Utilizaremos el siguiente esquema de un nodo para identificar los datos de una tarea: 
 
 
Inicio y Fin tempranos de una tarea se calculan en función de la finalización de las tareas que la preceden, es decir se 
calculan avanzando en la red. Inicio temprano está en relación del valor más alto de finalización de sus predecesoras. 
 
Inicio Temprano(n) = Max(Fin Temprano(predecesoras(n)) + 1. Inicio Temprano(0) = 0. 
Fin Temprano(n) = Inicio Temprano(n) + duración(n) – 1. 
Duración Total del Proyecto = Fin 
Inicio y Fin tardíos de una tarea se calculan una vez obtenido el valor de la duración total del proyecto y se calculan en 
función del inicio de las tareas que la suceden. Fin tardío está en relación al valor más bajo de inicio de sus sucesoras. 
Holgura libre: es el tiempo máximo que una tarea puede ser demorada sin que demore el inicio temprano de su 
sucesora. 
HL tarea(n) = Inicio temprano tarea(n + 1) – Fin Temprano tarea (n). 
 
Holgura total: es el tiempo máximo que una actividad puede ser demorada sin que se demore la fecha de finalización 
del proyecto. Esta holgura, si es cero, determina una tarea crítica. 
HT tarea (n) = Inicio Tardío (n) – Inicio Temprano (n) 
HT tarea (n) = Fin Tardio (n) – Fin Temprano (n) 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 11 
Ejemplo: Las tareas que conforman el camino crítico son “D” – “G” – “I” – “L” – “N” 
 
 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 12 
El Camino crítico es: 
• La secuencia de actividades críticas. 
• El más largo de todos los caminos 
• El camino con flotación cero (o mínima) 
 
Puede haber más de un camino crítico lo que generará más riesgo de demora del proyecto ya que una demora de una actividad del camino crítico causa la demora del 
proyecto. 
Para acortar la duración de un proyecto se debe recurrir a ajustar las actividades que componen el camino crítico. 
Puede ser útil reasignar recursos de una actividad no crítica a una crítica. 
El Director de Proyecto deberá poner mayor atención a las actividades críticas y a aquellas con flotación mínima. Existen métodos de simulación que permiten determinar 
cuáles son las actividades de un proyecto con mayor probabilidad de convertirse en críticas. 
 
El camino crítico no está definido solamente por los tiempos sino también por los recursos. Para ello es necesario desarrollar un histograma de recursos. La forma más fácil 
de realizar esto es desarrollar el diagrama de Gantt que se deriva del diagrama de Red, indicar para cada tipo de recurso el nivel de necesidad, marcar el nivel de disponibilidad y 
“aplanar” los recursos reasignando la definición de las tareas. Esto puede originar nuevamente un rearmado de la red definida anteriormente y el cambio del camino crítico. 
 
Según el ejemplo anterior el Diagrama de Gantt correspondiente quedaría: 
 
 Día 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 
 Duración 
TAREA A 2 
TAREA B 4 
TAREA C 2 
TAREA D 3 
TAREA E 9 
TAREA F 3 
TAREA G 8 
TAREA H 5 
TAREA I 4 
TAREA J 6 
TAREA K 3 
TAREA L 1 
TAREA M 2 
TAREA N 7 
TAREA O 3 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 13 
En el siguiente diagrama se muestran las estimaciones de recursos “Tipo 1” que se necesitarán para la realización de cada tarea. 
 
 Día 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 
 Dur. cant 
TAREA A 2 2 2 2 
TAREA B 4 0,5 0,5 0,5 0,5 0,5 
TAREA C 2 1 1 1 
TAREA D 3 0,5 0,5 0,5 0,5 
TAREA E 9 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 
TAREA F 3 0,25 0,25 0,25 0,25 
TAREA G 8 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 
TAREA H 5 1 1 1 1 1 1 
TAREA I 4 2 2 2 2 2 
TAREA J 6 0,25 0,25 0,25 0,25 0,25 0,25 0,25 
TAREA K 3 0,5 0,5 0,5 0,5 
TAREA L 1 2 2 
TAREA M 2 0,5 0,5 0,5 
TAREA N 7 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 
TAREA O 3 1 1 1 1 
Totales 4,25 4,25 2,25 2,25 2 2 2 1,25 1,25 1,25 0,75 2,25 2,25 2,25 2,25 2,5 0,75 1,25 1,25 1,25 0,25 0,25 0,25 
 
El histograma que se deduce de este diagrama es el siguiente: 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 14 
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
 
 
Como podemos ver, existe una sobreutilización de los recursos “Tipo 1” los días 1 y 2, lo que debería llevarnos a una nivelación de los mismos. Esto se realiza ajustando la 
flotación u holgura de las tareas tratando de no modificar la duración del Proyecto (es decir, sin tocar las tareas que corresponden al camino crítico). 
 
Si sólo se dispusiera de 2,5 recursos “Tipo 1” por día, ¿Se podría desarrollar una red donde no se modificara el camino crítico en función de esta disponibilidad? 
Los días críticos para estacantidad de recurso son los días 1 y 2 donde en el diagrama se superponen las tareas A, B, C, D y E. 
La D forma parte del camino crítico y siendo la suma de los recursos de las tareas A y D la que completa la disponibilidad para los días 1 y 2 moveremos las tareas B, C y E. 
Mover las tareas B y C repercuten en el inicio de la Tarea F pero ésta (que es predecesora de la I que forma parte del camino crítico) al tener holgura no repercute en la 
sucesora (todavía le queda una HT = 2). 
Mover la tarea E repercute en las tareas J, M y O convirtiéndolas en un nuevo camino crítico y aumentando el riesgo de tener 2 caminos críticos que controlar en lugar de 
uno. 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 15 
El nuevo Gantt con estas restricciones quedaría: 
 
 Día 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 
 Dur Cant 
TAREA A 2 2 2 2 
TAREA B 4 0,5 0,5 0,5 0,5 0,5 
TAREA C 2 1 1 1 
TAREA D 3 0,5 0,5 0,5 0,5 
TAREA E 9 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 
TAREA F 3 0,25 0,25 0,25 0,25 
TAREA G 8 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 0,5 
TAREA H 5 1 1 1 1 1 1 
TAREA I 4 2 2 2 2 2 
TAREA J 6 0,25 0,25 0,25 0,25 0,25 0,25 0,25 
TAREA K 3 0,5 0,5 0,5 0,5 
TAREA L 1 2 2 
TAREA M 2 0,5 0,5 0,5 
TAREA N 7 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 
TAREA O 3 1 1 1 1 
Totales 2,5 2,5 1 1,25 2,5 2,5 2 2,25 2,25 2,25 1,75 2,5 2,25 2,25 2,25 2,25 0,5 0,25 0,75 0,75 1,25 1,25 1,25 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 16 
 
El Histograma de Recursos “Tipo 1” que se deduce del nuevo Gantt: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
La nueva Red que se obtiene a partir de esta modificación: 
 
0
0,5
1
1,5
2
2,5
3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 17 
En el ejemplo anterior hemos mostrado la utilización de Diagramas de Gantt y Diagramas de Red. Las ventajas y 
desventajas que se deducen de su utilización son: 
 
Diagramas de Red: 
Ventajas 
• Identifican las relaciones entre actividades 
• Muestra el camino crítico 
• Reconoce interdependencias 
• Útil para estudios de ¿Qué pasaría si? 
Desventajas: 
• Puede convertirse en grande y complejo 
• Dificultoso de trasladar y mostrar 
• Requiere experiencia y entrenamiento 
 
 
Diagramas de Barra (Gantt): 
 Ventajas: 
• Fácil de construir, entender y cambiar 
• Muestra cuáles actividades están adelantadas o atrasadas 
Desventajas: 
• Difícil de mostrar datos de estado general del proyecto 
• Necesita aclaraciones para datos de porcentajes de realización 
 
 
MÉTODOS DE REDUCCIÓN DE LA DURACIÓN (SIN REDUCCIÓN DEL ALCANCE) 
 
Los Proyectos pueden ser limitados por el tiempo (fechas prefijadas) o limitados por los recursos (recursos 
escasos). 
Los Proyectos no serán factibles cuando tiempo y recursos son limitados y pueden no ser factibles cuando tiempo 
o recursos son limitados. 
Se recurre entonces a la reducción de la duración del Proyecto comenzando por las actividades que están en el 
camino crítico, reduciendo dependencias, aceptando el incremento del riesgo o considerando el aumento de los recursos 
en cantidad y/o calidad, aceptando el incremento del costo. 
 
 
• Fast Tracking: Actividades que normalmente deberían ser hechas en secuencia, realizarlas en paralelo. Puede 
incrementar el riesgo. 
• Crashing: Análisis de costo-tiempo para determinar cómo obtener la mayor reducción al menor costo. 
Incrementa el costo. 
 
 
 
Desarrollar el ejercicio de cálculo de asignación de actividades propuesto por la cátedra y discutir los resultados. 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 18 
CONTROL Y SEGUIMIENTO DEL PROYECTO 
 
El plan de Proyecto que incluye tiempos una vez aceptado conformará el “Baseline de Tiempos”. 
 
Si se ha desarrollado apropiadamente, define las tareas e hitos que deben seguirse y controlarse a medida que 
progresa el proyecto. 
El seguimiento y control puede hacerse de diferentes maneras: 
 
• Realizando reuniones periódicas del estado del proyecto en las que todos los miembros del equipo informan del 
progreso y de los problemas 
• Evaluando los resultados de todas las revisiones realizadas a lo largo del proceso de ingeniería del software (RTFs) 
• Determinando si se han conseguido los hitos formales del proyecto en la fecha programada 
• Comparando la fecha real de inicio con las previstas para cada tarea del proyecto listada en la tabla del proyecto 
• Reuniéndose informalmente con los profesionales del software para obtener sus valoraciones subjetivas del progreso 
hasta la fecha y los problemas que se avecinan. 
 
Una vez que un proyecto haya sido planificado, será necesario comparar los progresos con el plan, de forma que se 
pueda ejercer control y se pueda dar alguna indicación sobre lo bien que está siendo dirigido el proyecto. 
Los datos se recogen habitualmente asignando cargos a ciertas categorías de la contabilidad de costos, definidas 
mediante un sistema de plan de cuentas. En la fase de planificación, el plan de cuentas puede resultar también muy útil 
como lista de comprobación. Una de las mayores ayudas de una EDT es garantizar que no se haya olvidado ningún trabajo 
en el proyecto. 
Para poder realizar el seguimiento de los progresos contra el plan de cuentas, las personas afectadas al proyecto 
deberán registrar el tiempo dedicado al proyecto diariamente. Hay que utilizar un diagrama de responsabilidad lineal para 
mostrar quiénes son los responsables de las diversas actividades del proyecto. 
 
En el próximo capítulo: Gestión de Costos introduciremos un método para análisis de avance de proyecto en función 
de los tiempos y los costos del mismo. 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 19 
ESTIMACIÓN DE PROYECTOS DE SOFTWARE 
 
 
La estimación de proyectos de sistemas y tecnologías de información donde se requiera el desarrollo de software se 
presenta en términos de duración del proyecto, esfuerzo del personal que integra el equipo del proyecto (diferenciados por 
roles), y otros costos logísticos como equipamiento, licencias de software, etc. 
 
A pesar de que por definición la estimación de un proyecto es una predicción que siempre cuenta con ungrado de 
incertidumbre, en la industria del software el concepto de estimación en proyectos, se entrelaza frecuentemente con los 
conceptos de metas del negocio y con el establecimiento de compromisos: 
Una meta es una declaración de un objetivo del negocio del cliente: “Requerimos tener finalizado para el mes de Mayo 
la versión nn.nn del sistema X para cumplir con la nueva legislación”. 
Un compromiso es una promesa de entregar una funcionalidad definida, con un nivel específico de calidad, en una 
fecha establecida. 
 
Consecuencias de una mala estimación: 
• Efectividad reducida de la planeación 
• Reducción de las probabilidades de entregar un proyecto en término 
• Reducción del tiempo dedicado a actividades críticas del ciclo de vida como Análisis de Requerimientos o Diseño 
• Prácticas “destructivas” en las etapas finales del proyecto como: 
o Frecuentes reuniones con el cliente para discutir cómo avanzar con el proyecto 
o Frecuentes reestimaciones tardías del proyecto 
o Disculpas frecuentes a los clientes por no cumplir los plazos establecidos 
o Creación de versiones no completamente funcionales para demostrar algún tipo de progreso, pero bajo el 
riesgo de evidenciar públicamente problemas de calidad 
o Discusiones frecuentes acerca de los requerimientos que obligatoriamente deben ser adicionados, porque el 
proyecto se ha demorado demasiado 
o Depuración difícil de defectos introducidos por malas prácticas en el desarrollo en el que se incurren por la 
premura de las entregas 
 
Beneficios de las buenas prácticas en las estimaciones: 
• Visibilidad mejorada del estado de los proyectos 
• Mejora en la calidad 
• Mejor coordinación con roles de testing, documentación técnica, ventas, capacitación, entre otros 
• Mejora en los presupuestos 
• Información temprana acerca de los posibles riesgos 
 
Una “buena estimación” es aquella que proporciona una vista lo suficientemente clara de la realidad de un proyecto, la 
cual le permita a sus líderes tomar buenas decisiones acerca de cómo planear y controlar el proyecto para cumplir con sus 
metas. 
Para lograr realizar buenas estimaciones se debe contar con procesos organizacionales bien definidos e 
institucionalizados, donde el objetivo de estos sea el de minimizar las ambigüedades e incertidumbres que se presentan 
ante la realización de un proyecto de software a medida. 
 
Como hemos mencionado anteriormente en este capítulo la falta de información aumenta el rango de error en las 
estimaciones de un proyecto. 
Como una de las principales incertidumbres en las estimaciones proviene de la falta de conocimiento exacto de lo que 
se va a desarrollar, una estimación hecha en fecha temprana va a ser más imprecisa que una realizada más cerca del final 
del proyecto. Por supuesto, una vez terminado el proyecto, no hablamos ya de estimaciones, sino que podemos medir 
exactamente cuánto hemos tardado. 
Diversos autores han definido un “cono de incertidumbre”, que indica la variabilidad de una estimación a lo largo de un 
proyecto de desarrollo de software. Algunos opinan que el cono es simétrico, y otros destacan la asimetría que proviene de 
subestimar la cantidad de trabajo en las primeras etapas. A continuación se muestra un cono asimétrico típico: 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 20 
 
 
A medida que transcurren las etapas, la apertura del cono comienza a cerrarse, indicando que la incertidumbre va 
desapareciendo. Notemos que el estrechamiento de la incertidumbre no es automático. Supone que uno trabaja para 
acotar los requisitos del cliente, conocer cada vez más del dominio y de la arquitectura, tener más elementos tangibles 
(definición del producto, diseño de interfaz, diseño detallado) y disminuir el impacto de los posibles riesgos. Estos riesgos 
no son sólo la falta de conocimiento del producto a desarrollar sino que en esto pueden influir otros factores como 
enfermedades del personal, fallas en servicios como transporte o energía eléctrica, catástrofes naturales, u otros 
imponderables, cada uno con un grado de probabilidad. Estos riesgos deben ser administrados, pero indudablemente 
mantienen cierto grado de incertidumbre hasta el final. 
 
Las siguientes pueden ser causales de errores en la estimación: 
• Proceso de desarrollo caótico 
• Requerimientos inestables 
• Actividades o características omitidas 
• Optimismo infundado 
• Subjetividad y sesgo 
• Estimaciones superficiales 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 21 
FACTORES QUE INCIDEN EN LA ESTIMACIÓN DEL SOFTWARE 
 
 
TAMAÑO 
 
El tamaño del proyecto es un factor importante que puede afectar a la precisión de las estimaciones. A medida que el 
tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del software. 
Para medir el tamaño de un software existen varios criterios: número de líneas de código, número de interfaces propias 
del sistema (pantallas), número de interfaces con otros sistemas, número de casos de uso, etc. 
 
Muchas de estas medidas cuantitativas de la complejidad del software se aplican en el nivel de diseño y de codificación 
y por consiguiente son difíciles de utilizar durante la planificación de un software (antes de que exista un diseño o un 
código). Sin embargo, al comienzo del proceso de planificación se pueden establecer otras valoraciones de complejidad 
más subjetivas. 
 
DESECONOMÍAS DE ESCALA 
 
El número de integrantes de un proyecto es otro de los factores que afectan a la estimación. Con el número de 
integrantes de un proyecto ocurre un fenómeno contrario a lo que normalmente se cree. Si se incrementa el número de 
participantes de un proyecto no necesariamente disminuirá la fecha de finalización. Esto se debe básicamente a las 
deseconomías de escala, las cuales implican que a mayor número de participantes, los canales de comunicación aumentan 
exponencialmente, dando como trabajo adicional un esfuerzo en la coordinación de todos los recursos. 
 
TIPOS DE SOFTWARE 
 
Todos los tipos de software llevan consideraciones diferentes para su desarrollo, ya que las especificaciones varían y 
afectan de diferente forma a la duración del proyecto. Podríamos pensar las diferencias entre los siguientes tipos de 
software: aviación, sistemas de negocio, comando y control, sistemas embebidos, aplicaciones web, sistemas diseñados 
para intranets, micro código, control de procesos, tiempo real, sistemas científicos o de investigación en ingeniería, 
productos de software licenciado, drivers, telecomunicaciones, etc. 
 
FACTORES DEL PERSONAL 
 
Las habilidades del personal son otro de los factores que afectan a la estimación. Las competencias encontradas en un 
equipo de trabajo pueden disminuir o aumentar el esfuerzo requerido para realizar una tarea dentro del ciclo de desarrollo 
de un proyecto de software. 
 
LENGUAJE DE PROGRAMACIÓN 
 
El conocimiento de un equipo de desarrollo acerca de los lenguajes y de las herramientas sobre las cuales se puede 
trabajar, es un factor a tener en cuenta si el equipo de trabajo no cuenta con la suficiente experiencia, dado que afecta el 
tiempo esperado de construcción. 
También es necesario revisar las características que ofrece el lenguaje seleccionado ya que dependiendo de las mismas 
estará enfocado a diferentes objetivos de productividad. 
Actualmente hay que resaltar el impacto que tienen los IDE (Integrated Development Environment) en la variación de la 
productividad de producción. En general facilitan procesos detección de errores,seguimientos a variables en el código, 
generación y despliegue del producto, comunicación con otros sistemas, etc. 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 22 
TÉCNICAS DE ESTIMACIÓN PARA PROYECTOS DE SOFTWARE 
 
Las técnicas que mencionaremos a continuación están destinadas a reducir la complejidad en la estimación de 
proyectos de software. Por esta razón descomponen el problema volviéndolo a definir como un conjunto de pequeños 
problemas, esperando que sean más manejables. El enfoque de descomposición se puede estudiar desde dos puntos de 
vista diferentes: descomposición del problema y descomposición del proceso. La estimación hace uso de una o ambas 
formas de particionamiento, pero antes de hacer una estimación, el planificador debe comprender el ámbito del software a 
construir y generar una estimación de su “tamaño”. 
 
Las dos técnicas más utilizadas para medir el tamaño del software son Líneas de Código y Puntos de Función. 
 
 Si se toma un enfoque directo, el tamaño se puede medir en LDC (líneas de código – métrica orientada al tamaño). Si se 
selecciona un enfoque indirecto, el tamaño se puede representar como PF (puntos de función – métrica orientada a la 
función). 
 
Si bien en la actualidad la medición directa por LDC no se adapta al software que se produce, existen buenas 
conversiones entre éstas y los enfoques indirectos por lo que resulta conveniente su entendimiento. 
Otra técnica que ha comenzado a utilizarse es la de Puntos de Casos de Uso, debido al creciente uso del modelado de 
requisitos mediante esta técnica. 
 
 
Las métricas orientadas al tamaño provienen de la normalización de las medidas de calidad y/o productividad 
considerando el tamaño del software que se haya producido. 
Si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño, 
en la que se pueden listar cada uno de los proyectos de desarrollo de los últimos años y las medidas correspondientes a 
cada proyecto: LDC, esfuerzo (personas-mes) y costo, teniendo en cuenta de que el mismo incluye todas las actividades de 
ingeniería del software (análisis, diseño, codificación y prueba). 
Otra información importante pueden ser otras métricas tales como la cantidad de páginas de documentación, la 
cantidad de errores encontrados en la etapa de prueba y la cantidad de errores después de entregado al cliente dentro del 
primer año de utilización. 
 
Los valores que se obtienen de las técnicas de PF o LDC sirven para estimar los valores de las variables nombradas 
anteriormente utilizando valores promedios de proyectos anteriores. Por ejemplo para estimar el esfuerzo de un proyecto 
se puede realizar: 
 
Esfuerzo = PF/productividad-media(PF/personas-mes) = personas-mes 
 
para el proyecto total o estimar cada subfunción utilizando un valor de productividad-media que varíe dependiendo de la 
complejidad de cada subfunción. Para esta última estimación se utilizan la descomposición del problema y del proceso en 
forma conjunta. 
 
Un modelo común de estimación se extrae utilizando el análisis de regresión sobre los datos de proyectos de software 
anteriores. La estructura global de los modelos de estimación adquiere la forma de 
 
E = A + B x (ev)^c 
 
Donde E es el esfuerzo en personas-mes y A,B,C son constantes obtenidas empíricamente y ev es la variable de 
estimación (LDC o PF). Además los modelos de estimación tienen algún componente de ajuste del proyecto que permite 
ajustar E por otras características del proyecto (por ej. Complejidad de problema, experiencia del personal, entorno de 
desarrollo). 
 
 
 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 23 
ESTIMACIÓN POR LÍNEAS DE CÓDIGO. EL MODELO COCOMO 
 
COnstructive COst MOdel – Modelo constructivo de Costo) es un modelo empírico de estimación basado en LDC 
 
Existen 3 jerarquías de modelos 
1. Básico: calcula el esfuerzo (y costo) en función del tamaño del programa expresado en LDC 
2. Intermedio: calcula el esfuerzo del desarrollo en tamaño del programa y de un conjunto de “conductores de costo” 
que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto 
3. Avanzado: incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los 
conductores en cada fase (análisis, diseño, etc.) del proceso de ingeniería del software 
 
Los modelos COCOMO están definidos para tres tipos de proyectos de software 
1. Orgánico: proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena 
experiencia en la aplicación, sobre un conjunto de requisitos poco rígidos 
2. Semiacoplado: proyectos intermedios en tamaño y complejidad en los que equipos, con variados niveles de 
experiencia, deben satisfacer requisitos poco o medio rígidos 
3. Empotrado: proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones 
operativas muy restringido. 
 
Las ecuaciones del COCOMO básico tienen la forma: 
 
E = a x KLDC^b 
D = c x E^d 
Donde E es el esfuerzo en personas-mes, D es el tiempo de desarrollo en meses cronológicos y KLDC es el número estimado 
de líneas de código (en miles) para el proyecto. 
Los coeficientes a y c y los exponentes b y d están tabulados: 
 
Proyecto A b C d 
Orgánico 2,4 1,05 2,5 0,38 
Semiacoplado 3,0 1,12 2,5 0,35 
Empotrado 3,6 1,20 2,5 0,32 
 
 
La ecuación del COCOMO intermedio toma la forma: 
 
E = a x KLDC^b x FAE 
Donde E es el esfuerzo en personas-mes KLDC es el número estimado de líneas de código (en miles). FAE es el factor d 
ajuste de complejidad que varía entre 0,9 a 1,4 dependiendo de la valoración de ciertos atributos del producto, hardware, 
personal y proyecto (ver tablas publicadas por Boehm en el libro Economía de la Ingeniería del Software). 
El coeficiente a y el exponente b están tabulados: 
 
Proyecto a b 
Orgánico 3,2 1,05 
Semiacoplado 3,0 1,12 
Empotrado 2,8 1,20 
 
 
El uso de LDC como parámetro para medir el tamaño es un tema controversial y se pueden citar las siguientes ventajas y 
desventajas de su uso: 
Ventajas: 
• Los datos históricos de LDC de proyectos anteriores se pueden recolectar automáticamente con herramientas 
• Existen muchos datos históricos de organizaciones expresados en LDC 
• Las métricas de LDC permiten la comparación de proyectos 
• La mayoría de las herramientas de estimación basan el cálculo del esfuerzo y del cronograma en LDC 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 24 
Desventajas: 
• Son tendientes al error debido a las deseconomías de escala y a las diferencias de métricas de productividad 
para distintos tipos de software. 
• No pueden ser utilizadas para tareas individuales debido a las diferencias de productividad entre distintos 
programadores 
• Un proyecto que requiera mayor complejidad en el código que los utilizados para calibrar los supuestos de 
productividad (información histórica de proyectos anteriores) puede afectar la exactitud de la estimación 
• Los indicadores de LDC son altamente dependientes del lenguaje de programación, por lo cual un proyecto que 
utilizará otro lenguaje de programación diferente al medido por los datos históricos no puede utilizar éstos 
como base para lacalibración 
• Usar la métrica LDC para estimar el esfuerzo de análisis de requerimientos, diseño y otras actividades no 
relacionadas con la codificación parece no intuitivo 
• La definición de lo que constituye una línea de código debe ser detallado y documentado para evitar problemas 
 
 
 
ESTIMACIÓN POR PUNTOS DE FUNCIÓN. MÉTODO DE ALBRECHT. 
 
 
Para proceder al cálculo de los puntos función de un sistema han de realizarse tres etapas: 
1. Identificación de los componentes necesarios para el cálculo. 
2. Cálculo de los Puntos Función no ajustados. 
3. Ajuste de los Puntos Función. 
 
IDENTIFICACIÓN DE LOS COMPONENTES 
 
En esta etapa se identifican los elementos a tener en cuenta para el cálculo de los puntos función. Primeramente se 
enumeran todos los componentes de cada tipo (entradas externas, salidas externas, grupos lógicos de datos internos, 
grupos lógicos de datos de interfaz y consultas externas); seguidamente, se evalúa individualmente la complejidad de cada 
uno de ellos, utilizando unas tablas ya establecidas que proporcionan el factor de complejidad de cada componente 
individual, siendo estos factores: COMPLEJO, MEDIO o SENCILLO. 
 
A continuación se describen los distintos componentes que han de tenerse en cuenta para el cálculo y la forma de 
determinar su complejidad en cada caso. 
 
Grupos lógicos de datos internos 
− Son aquellos grupos lógicos de datos o información de control interna que se generan, son usados y mantiene la 
aplicación. 
− No deben incluirse aquellos grupos lógicos de datos que no sean accesibles por el usuario a través de entradas o 
salidas externas, ficheros de interfaz o consultas. 
 
 
 
Grupos lógicos de datos de interfaz o externos 
− Son aquellos grupos lógicos de datos compartidos con otra aplicación, recibidos o enviados a ella. 
− Los grupos lógicos internos que son a su vez interfaz, deben contarse en ambos grupos. 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 25 
Para el análisis de los grupos lógicos de datos internos o externos se utiliza la siguiente matriz de complejidad: 
 
 
Entradas externas 
 
− Son todos aquellos grupos de datos o mandatos de control de usuario que entran en la aplicación y añaden o 
cambian información en un grupo lógico de datos interno. 
− Una entrada es única si difiere en su formato o si arranca procesos diferentes. 
 
Para el análisis de este componente se utiliza la siguiente matriz de complejidad: 
 
 
Salidas externas 
− Son todos aquellos grupos lógicos de datos o mandatos de control de usuario que salen de la aplicación. 
− Una salida es única si difiere en su formato o si es generada por procesos lógicos diferentes. 
 
Para el análisis de este componente se utiliza la siguiente matriz de complejidad: 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 26 
Consultas externas 
− Son entradas de usuario u otra aplicación que generan una salida inmediata. 
− Son consecuencia de una búsqueda y no una actualización de un grupo lógico de datos interno. 
− Se utilizará la matriz de Entradas Externas para calificar la parte correspondiente a la entrada. 
− Se utilizará la matriz de Salidas Externas para calificar la parte correspondiente a la salida. 
− Se seleccionará la más compleja. 
 
 
 
CÁLCULO DE LOS PUNTOS FUNCIÓN NO AJUSTADOS 
 
Una vez concluida la etapa anterior se pasan los resultados a la tabla de conversión, que aparece a continuación, dando 
un peso para cada tipo de componente por su complejidad. 
 
 
 
Una vez calculado el número de funciones y determinada su complejidad, no hay más que llevar los valores obtenidos a 
la tabla. La suma de los resultados parciales da el valor en PUNTOS FUNCIÓN NO AJUSTADOS (PFNA). 
 
 
 
AJUSTE DE LOS PUNTOS FUNCIÓN 
 
 
Esta etapa tiene como objetivo la adaptación de la estimación a las condiciones de trabajo bajo las que el sistema ha de 
ser desarrollado. De esta adaptación se obtiene el valor definitivo en Puntos Función del Sistema que se está evaluando, 
aplicándole correcciones dependiendo de las características de la aplicación que afecten a la complejidad de la misma. 
Existen 14 atributos de ajuste que impactan en el desarrollo y que deben ser evaluados, si bien se evalúan 
independientemente. 
A cada atributo se le asignará un valor entre 0 y 5, dependiendo del grado de influencia de éstos. Los posibles valores 
son: 
Sin influencia (0). El sistema no contempla este atributo. 
Influencia mínima (1). La influencia de este atributo es muy poco significativa. 
Influencia moderada (2). El sistema contempla este atributo y su influencia, aunque pequeña, ha de ser considerada. 
Influencia apreciable (3). La importancia de este atributo debe ser tenida en cuenta, aunque no es fundamental. 
Influencia significativa (4). Este atributo tiene una gran importancia para el Sistema. 
Influencia muy fuerte (5). Este atributo es esencial para el Sistema y ha de ser tenido en cuenta a la hora del diseño. 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 27 
Los 14 atributos que se contemplan en esta técnica y sus significados aparecen a continuación. 
1. Comunicación de datos. Los posibles valores para este atributo son: 
0. La aplicación es un proceso por lotes puro. 
1. Proceso por lotes con impresión remota o entrada remota de datos. 
2. Proceso por lotes con impresión remota y entrada remota de datos . 
3. El Teleproceso es la interfaz para un proceso por lotes. 
4. La aplicación está basada en un teleproceso interactivo, pero con un solo protocolo de comunicaciones. 
5. La aplicación está basada en un TP interactivo, pero con más de un protocolo de comunicaciones. 
 
2. Funciones distribuidas: Funciones de datos o procesos distribuidas. Los posibles valores para este atributo son: 
0. La aplicación no tiene el objetivo de transferir datos o funciones procesadas entre dos sistemas. 
1. Datos preparados de la aplicación para su procesamiento por el usuario final sobre otro componente del sistema. 
2. La aplicación prepara los datos para procesarlos sobre otra máquina diferente (no usuario final). 
3. Proceso distribuido, en línea, con transferencia de datos en una única dirección. 
4. Como el anterior, pero con transferencia de datos en ambas direcciones. 
5. Las funciones de proceso se realizan dinámicamente sobre el componente del sistema más apropiado. 
 
3. Prestaciones: Consideración en el diseño, instalación y mantenimiento de factores de rendimiento como el tiempo de 
respuesta, la capacidad de proceso, etc. Los posibles valores para este atributo son: 
0. No hay requerimientos especiales 
1. Se establecen requerimientos para las prestaciones, pero sin tratamiento específico. 
2. Respuesta crítica del proceso en línea durante las horas pico. No hay especificaciones para la utilización de CPU. 
3. Respuesta crítica del proceso en línea durante los días laborables. No hay especificaciones para la utilización de 
CPU. Proceso afectado por aplicaciones de interfaz. 
4. Las tareas de análisis de las prestaciones se incluyen en la fase de diseño para establecer los requerimientos de 
usuario. 
5. Además, se emplearán herramientas específicas para el diseño que contemplen estas características. 
 
4. Gran uso de la configuración: Cuando además de los objetivos de rendimiento se considera una gran utilización.El 
usuario ha de utilizar la aplicación en un entorno bastante cargado. Los posibles valores para este atributo son: 
0 – 3. Típica aplicación sobre máquina de producción, sin restricciones de operación declaradas. 
4. Las restricciones de operación declaradas requieren imperativos especiales sobre la aplicación en el procesador 
central. 
5. Además, existen imperativos especiales sobre la aplicación en componentes distribuidos del sistema. 
 
5. Velocidad de las transacciones: Número alto de transacciones por unidad de tiempo que influyen en el diseño, 
instalación y posterior mantenimiento. Los posibles valores para este atributo son: 
0. Las transacciones no están afectadas por picos de tráfico. 
1. 10% de transacciones afectadas por los picos de tráfico. 
2. 50% de transacciones afectadas por los picos de tráfico. 
3. 100% de transacciones afectadas por los picos de tráfico. 
4. Se incluyen tareas de análisis para las funciones en la fase de diseño para lograr los altos índices de función 
declarados por el usuario en los requerimientos de la aplicación o acuerdos de nivel de servicio (SLA). 
5. Además, se utilizan herramientas de análisis para las prestaciones en las fases de diseño, desarrollo y / o 
instalación para lograr los altos índices de función declarados por el usuario en los requerimientos de la aplicación 
o acuerdos de nivel de servicio (SLA). 
 
6. Entrada de datos en línea: La toma de datos de la aplicación se realiza en línea. Los posibles valores para este atributo 
son: 
0. Todas las transacciones son tratadas por lotes. 
1. Entre el 1 y el 7% de las funciones son entradas interactivas de datos. 
2. Entre el 8 y el 15% de las funciones son entradas interactivas de datos. 
3. Entre el 16 y el 23% de las funciones son entradas interactivas de datos. 
4. Entre el 24 y el 30% de las funciones son entradas interactivas de datos. 
5. Más del 30% de las funciones son entradas interactivas de datos. 
 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 28 
7. Diseño para la eficiencia del usuario final: Se incluyen tareas de diseño para consideraciones especiales del usuario en 
la Fase de Diseño para atender los requerimientos del usuario, por ejemplo: 
o Ayuda de navegación. 
o Menús. 
o Ayuda en línea. 
o Movimiento automático del cursor. 
o Scrolling. 
o Impresión remota. 
o Teclas de función preestablecidas. 
o Procesos por lotes lanzados desde transacciones en línea. 
o Selección de datos con el cursor. 
o Gran uso de facilidades en el monitor (colores, textos resaltados, etc.). 
o Copia impresa de las transacciones en línea. 
o Mouse. 
o Windows. 
o Pantallas reducidas. 
o Bilingüismo. 
o Multilingüismo. 
Los posibles valores para este atributo son: 
0. No se han declarado ninguno de los anteriores requerimientos especiales de usuario. 
1. De 1 a 3 de los requerimientos de la lista. 
2. 4 ó 5 requerimientos de la lista. 
3. Más de 6 requerimientos de la lista. 
4. Se incluyen en la fase de diseño tareas de diseño para consideraciones de factores humanos para lograr los 
requerimientos de usuario declarados. 
5. Además, se usan herramientas especiales o prototipos para suscitar la eficiencia del usuario final. 
 
8. Actualización de datos en línea: Los datos internos se actualizan mediante transacciones en línea. Los posibles valores 
para este atributo son: 
0. Ninguna. 
1. y 2. Actualización en línea de ficheros de control. 
3. Actualización en línea de ficheros importantes internos. 
4. También, se considera esencial la protección contra pérdida de información. 
5. Además, grandes volúmenes implican consideraciones de coste en el proceso de recuperación. 
 
9. Complejidad del proceso lógico interno de la aplicación: Se considera complejo cuando hay muchas interacciones, 
puntos de decisión o gran número de ecuaciones lógicas o matemáticas. ¿Cuál de las siguientes características tienen 
aplicación para la aplicación? 
o Extensiones de proceso lógicas. 
o Extensiones de proceso matemáticas. 
o Muchos procesos de excepción, muchas funciones incompletas y muchas iteraciones de funciones. 
o Procesos sensibles de control y / o seguridad. 
o Procesos complejos de manejo de múltiples posibilidades de Entrada / Salida (por ejemplo: multimedia, 
independencia de dispositivos,etc.). 
Los posibles valores para este atributo son: 
0. Ninguno de los anteriores es aplicable. 
1. Es aplicable uno de los anteriores. 
2. Son aplicables dos de los anteriores. 
3. Son aplicables 3 de los anteriores. 
4. Son aplicables 4 de los anteriores. 
5. Todos ellos son aplicables. 
 
10. Reusabilidad del código por otras aplicaciones. Los posibles valores para este atributo son: 
0. No hay que reutilizar el código. 
1. Se emplea código reusable dentro de la aplicación. 
2. Menos del 10% de la aplicación se considera reusable. 
3. El 10% o más de la aplicación se considera reusable. 
UNIVERSIDAD TECNOLOGICA NACIONAL - FACULTAD REGIONAL ROSARIO – SISTEMAS DE INFORMACION 
 
Asignatura: ADMINISTRACION DE RECURSOS 
Unidad 1: Administración de Proyectos de Sistemas y Tecnologías de la Información 
Capítulo 4: Gestión de Tiempos 
 
Lic. Fabiana María Riva Abril 2010 29 
4. La aplicación está específicamente preparada y documentada para facilitar la reutilización y se adapta sobre código 
fuente. 
5. La aplicación está específicamente preparada y documentada para facilitar la reutilización y, además, se adapta 
sobre parámetros. 
 
11. Facilidad de instalación: Durante el desarrollo se consideran factores que facilitan la posterior conversión e instalación. 
Los posibles valores para este atributo son: 
0. El usuario no ha declarado consideraciones especiales para instalación y conversión. 
1. El usuario no ha declarado consideraciones especiales para instalación y conversión, pero se requiere un set 
especial para la instalación. 
2. El usuario ha declarado consideraciones especiales para la conversión e instalación y se requieren guías probadas 
de conversión e instalación. 
3. El usuario ha declarado consideraciones especiales para la conversión e instalación y se requieren guías probadas 
de conversión e instalación y se considera importante el impacto. 
4. El usuario ha declarado consideraciones especiales para la conversión e instalación y se requieren guías probadas 
de conversión e instalación y, además, se facilitan herramientas probadas para la conversión e instalación. 
5. El usuario ha declarado consideraciones especiales para la conversión e instalación y se requieren guías probadas 
de conversión e instalación, considerándose importante el impacto. Además, se facilitan herramientas probadas 
para la conversión e instalación. 
 
 
12. Facilidad de operación: Se han tenido en cuenta factores de operatividad. Se han considerado procedimientos de 
arranque, de copia de respaldo y de recuperación. Los posibles valores para este atributo son: 
0. No hay consideraciones especiales de operación. 
1 – 2. Se requieren procesos específicos de arranque, back-up y recuperación debidamente probados. 
3 - 4 Además, la aplicación debe minimizar las necesidades de operaciones manuales, como manejo de papeles o 
montaje de cintas. 
5. La aplicación debe diseñarse para una operación totalmente automática. 
 
13. Localizaciones múltiples: La aplicación se diseña para ser utilizada en diversas instalaciones y por organizaciones. El 
valor para este atributo será la suma de los aplicables: 
0. No hay requerimientos de usuario para más de un lugar. 
1. Se consideran múltiples instalaciones pero con idéntica configuración (tanto hardware como software). 
2. Se consideran múltiples instalaciones pero con similar configuración (tanto hardware como software). 
3. Se consideran múltiples instalaciones pero con diferente configuración (tanto