estimación y calendarización para proyectos software. · estimaciÓn de tiempo y costo de...

ESTIMACIÓN DE TIEMPO Y COSTO

DE PRODUCTOS SOFTWARE 2013

Página 1 de 12

Estimación y calendarización para proyectos software.

Antes de que el proyecto comience el gestor del proyecto y el equipo de software deben estimar

el trabajo que habrá que realizarse, los recursos que se requerirán y el tiempo que transcurrirá

desde el principio hasta el final. Una vez que se completen estas actividades, el equipo de

software debe establecer un plan del proyecto que defina las tareas y fechas clave de la ingeniería

del software, que identifique quién es responsable de dirigir cada tarea y especifique las

dependencias entre tareas que pueden ser determinantes en el progreso.

Siempre que se realizan estimaciones se atisba al futuro y se acepta automáticamente algún grado

de incertidumbre. Aunque la estimación es tanto un arte como una ciencia, esta importante

actividad no necesita realizarse en una forma improvisada. Existen técnicas para la estimación de

tiempo y esfuerzo. La experiencia puede auxiliar enormemente conforme se desarrolla y revisan

las estimaciones.

La estimación del costo y el esfuerzo nunca será una ciencia exacta. Demasiadas variables-

humanas, técnicas, ambientales, políticas- pueden afectar el costo final del software y el esfuerzo

aplicado a desarrollarlo. Para lograr estimaciones confiables de costo y esfuerzo se tienen varias

opciones:

1. Demorar la estimación hasta tarde en el proyecto (obviamente, se logra el 100% de

estimación precisa después de que el proyecto esté terminado)�no es práctica, porque

la estimación de costos se tiene que proporcionar por adelantado.

2. Basar las estimaciones en proyectos similares que ya hayan sido completados.

3. Emplear técnicas de descomposición relativamente simples para generar estimaciones de

costo y esfuerzo del proyecto.

4. Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo.

Proceso de planificación del proyecto

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que

permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Además las

estimaciones deben intentar definir los escenarios de mejor y peor caso de modo que los

resultados del proyecto se puedan acotar. Aunque existe un grado inherente de incertidumbre, el

equipo de software se embarca en un plan establecido como consecuencia de las tareas de

planificación. Por lo tanto, el plan se debe adaptar y actualizar conforme avance el proyecto

Ámbito del software y factibilidad

El ámbito del software describe las funciones y características que se entregarán a los usuarios

finales, los datos que son entrada y salida, el contenido que se presenta a los usuarios como

consecuencia de emplear el software, así como el desempeño, las restricciones, las interfases y la

confiabilidad que acotan el sistema. El ámbito se define al usar una de las dos técnicas siguientes:



Página 2 de 12

1. Despues de una comunicación con todos los participantes se desarrolla una descripción

narrativa del ámbito del software.

2. Los usuarios finales desarrollan un conjunto de casos de uso.

Las consideraciones del desempeño abarcan los requisitos de procesamiento y tiempo de

respuesta. Las restricciones identifican los limites colocados en el software por el hardware

externo , la memoria disponible u otros sistemas existentes.

Una vez identificado el ámbito es razonable preguntar: ¿es posible construir software para

satisfacer este ámbito? ¿El proyecto es factible?

Recursos: humanos, de software reutilizables, del entorno

La segunda tarea de la planificación es la estimación de los recursos necesarios para completar el

esfuerzo de desarrollo del software. La siguiente figura muestra las tres grandes categorías de los

recursos de ingeniería del software: personal, componentes de software reutilizables y el entorno

de desarrollo.

Aclaración: Componentes OTS, son componentes fuera de la plataforma.

� Recursos humanos

El planificador comienza evaluando el ámbito del software y seleccionando las habilidades

requeridas para completar el desarrollo. Se especifican tanto la posición organizacional (por

ejemplo, gestor, ingeniero de software ejecutivo) como la especialidad (por ejemplo,

telecomunicaciones, base de datos, cliente/servidor). En proyectos relativamente pequeños



Página 3 de 12

(unos pocos persona-mes) un solo individuo puede realizar todas las tareas de ingeniería del

software y consultar con especialistas conforme se requiere. En proyectos mayores el equipo

de software puede estar geográficamente disperso en varios sitios. Aquí se especifica la

ubicación de cada recurso humano.

� Recursos de software reutilizables

La ingeniería del software basada en componentes enfatiza la creación y reutilización de

bloques de construcción de software. Tales bloques, usualmente llamados componentes,

deben catalogarse para consultarlos con facilidad, estandarizarse para facilitar su aplicación y

validarse para integrarlos fácilmente.

Se sugieren cuatro categorías de recursos de software que deben considerarse conforme

avanza la planificación:

• Componentes ya desarrollados: se obtiene de un tercero o se desarrolló internamente

por un proyecto previo.

• Componentes experimentados: especificaciones, diseños, código o datos de prueba

existentes que se desarrollaron para proyectos previos son similares al software que se

constituirá para el proyecto actual.

• Componentes de experiencia parcial: especificaciones, diseños, código o datos de prueba

existentes que se desarrollaron para proyectos previos están relacionados con el software

que se construirá para el proyecto actual pero requerirán modificaciones sustanciales. Los

miembros del equipo de software actual solo tienen experiencia limitada en el área de

aplicación que representan dichos componentes.

• Componentes nuevos: el equipo de software debe construir los componentes de software

específicamente para las necesidades del proyecto actual.

Irónicamente, con frecuencia los componentes de software reutilizables son despreciados

durante la planificación, sólo para convertirse en una preocupación importante durante la fase

de desarrollo del proceso de software.

� Recursos del entorno

El entorno que soporta un proyecto de software, denominado entorno de ingeniería del

software (EIS), incorpora hardware y software. El hardware proporciona una plataforma que

soporta las herramientas (software) con que se producen los productos de trabajo basados en

una buena práctica de la ingeniería del software. El planificador de proyecto debe prescribir la

ventana de tiempo requerida por el hardware y el software, y verificar que estos recursos

estarán disponibles.



Página 4 de 12

Técnicas de descomposición

La estimación del proyecto es una forma de resolver problemas; en la mayoría de los casos, el

problema que debe resolverse es muy complejo como para considerarlo una sola pieza, por esta

razón se descompone el problema, re caracterizándolo como un conjunto de problemas más

pequeños.

� Tamaño del software

Puesto que la estimación de un proyecto sólo es tan buena como la estimación del tamaño del

trabajo para realizarlo, el tamaño representa el primer gran desafío del planificador del

proyecto. En el contexto de la planificación del proyecto, tamaño se refiere a un resultado

cuantificable del proyecto de software.

Algunos enfoques al problema del tamaño son:

• Tamaño de componentes estándar. El software se compone de varios “componentes

estándar”, los cuales son diferentes y genéricos de un área particular de la aplicación.

Por ejemplo, los componentes estándar de un sistema de información son

subsistemas, módulos, pantallas reportes, etc.

• Tamaño del cambio. Este enfoque se aplica cuando un proyecto incluye la utilización

de software existente que debe modificarse en cierta forma como parte de un

proyecto.

� Estimación basada en el problema

Las estimaciones de LDC (líneas de código) y PF (puntos de función) son distintas técnicas de

estimación, aunque ambas tienen varias características en común. El planificador del proyecto

comienza con un enfoque acotado del ámbito del software y a partir de ahí intenta

descomponer el software en funciones problema que pueda estimarse individualmente.

Entonces se estiman las LDC o PF para cada función. De manera alternativa, el planificador

puede elegir otro componente para tamaño, como clases u objetos, cambios o procesos de

negocios afectados.

Las técnicas de estimación LDC y PF difieren en cuanto al detalle requerido para

descomposición y el objetivo de la partición. Al emplear LDC como variable de estimación la

descomposición es absolutamente esencial y con frecuencia se lleva a grados considerables de

detalle. Mientras mayor sea el grado de partición es más probable que se desarrolle una

estimación razonablemente precisa de LDC.

Sin importar la variable de estimación que se utilice, el planificador del proyecto comienza

estimando una gama de valores para cada función o valor de dominio de información. Al



Página 5 de 12

emplear datos históricos o intuición, el planificador estima un valor de tamaño optimista, más

probable, y pesimista para cada función o cuenta para cada valor de dominio de información.

Entonces se puede calcular un valor de tres puntos o uno esperado. El valor esperado para la

variable de estimación (tamaño), S, se calcula como un promedio ponderado de las

estimaciones (Sopt), más probable (Sm) y pesimista (Spes). Por ejemplo:

S = (Sopt + 4Sm + Spes)/6

� Un ejemplo de estimación basada en LDC

Considérese un paquete de software que será entregado para una aplicación de diseño

asistido por computadora (CAD) destinado a componentes mecánicos. El software se ejecutará

en una estación de trabajo de ingeniería y debe tener interfaz con varios periféricos que

incluyen ratón, digitalizador, monitor de color de alta resolución e impresora láser. Se puede

elaborar una descomposición del ámbito del software:

El software CAD mecánico aceptará del ingeniero datos geométricos de dos o tres

dimensiones. El ingeniero interactuará y controlará el sistema CAD a través de una interfaz

del usuario que exhibirá características de buen diseño de interfaz humano-máquina.

Todos los datos geométricos y otra información de soporte se conservarán en una base de

datos CAD. Se desarrollarán módulos de análisis de diseño para producir la salida

requerida, la cual se desplegará en una diversidad de dispositivos gráficos. El software se

diseñará para controlar e interactuar con dispositivos periféricos que incluyan ratón,

digitalizador, impresora láser y plotter.

Esta descripción del ámbito es preliminar, no está acotada. Se tendría que expandir cada

oración para ofrecer detalle concreto y acotación cuantitativa. Por ejemplo: cuáles serán el

tamaño y la complejidad de la base de datos CAD.

Al continuar con la técnica de descomposición para LDC se elaborara una tabla de estimación,

la cual se muestra en el siguiente cuadro:

Función LDC estimados

Facilidades de interfaz del usuario y control (FIUC)

Análisis geométrico bidimensional (AG2D)

Análisis geométricos tridimensional (AG3D)

Gestión de base de datos (GBD)

Facilidades de presentación gráfica de computadora (FPGC)

Función de control periférico (FCP)

Módulos de análisis de diseño (MAD)

2300 5300 6800 3350 4950 2100 8400

Líneas de código estimadas 33200



Página 6 de 12

Una revisión de los datos históricos indica que el promedio organizacional de productividad

para sistemas de este tipo es de 620 LDC/pm. Con base en una tarifa laboral de 8000 dólares

por mes, el costo por línea de código es aproximadamente de 13 dólares (8000/620). Con base

en la estimación del proyecto es de 431600 dólares (33200*13) y el esfuerzo estimado es de

54 personas-mes (33200/620).

� Un ejemplo de estimación basada en PF

La descomposición de la estimación basada en PF se centra en los valores de dominio de

información más que en las funciones de software. Al consultar la tabla siguiente el

planificador del proyecto estima entradas externas, salidas externas, consultas externas,

archivos lógicos internos archivos de interfaz externos para el software CAD.

Valor de dominio de información Optim. Probable Pesim.

Conteo Estim.

Peso Conteo

PF Número de entradas externas

Número de salidas externas

Número de preguntas externas

Número de archivos lógicos internos

Número de archivos de interfaces externos

20

12

16

4

2

24

15

22

4

2

30

22

28

5

3

24

16

22

4

2

4

5

5

10

7

97

78

88

42

15

Conteo total 320

Se estima cada uno de los factores ponderados de complejidad y el valor del factor ajustado se

calculan de la siguiente forma:

Factor Valor

1 2 3 4 5 6 7 8 9

10 11 12 13 14

Respaldo y recuperación

Comunicaciones de datos

Procesamiento distribuido

Desempeño crítico

Entorno operativo existente

Entrada de datos en línea

Transacción de entrada sobre pantallas múltiples

ILF(archivos lógicos internos) actualizado en línea

Complejo de valores de dominio de información

Complejo de procesamiento interno

Código diseñado para reutilización

Conversión/instalación en diseño

Instalación múltiples

Aplicación diseñada para cambio

4

2

0

4

3

4

5

3

5

5

4

3

5

5

Factor de ajuste de valor 1.17

Finalmente, se deriva el número estimado de PF:

PFestimado= conteo total x [0.65 + 0.01 x ∑(Fi)]



Página 7 de 12

PFestimado= 375

La productividad organizacional promedio para sistemas de este tipo es 6.5 PF/pm. Con base

en una escala salarial de 8000 dólares por mes, el costo por PF es aproximadamente 1230

dólares. Con base en la estimación de PF y los datos de productividad históricos, el costo total

estimado del proyecto es de 461000 dólares, y el esfuerzo estimado es de 58 persona-mes.

Modelos empíricos de estimación

Los datos empíricos que apoyan la mayoría de los modelos de estimación proceden de una

muestra limitada de proyectos. Por esta razón, ningún modelo de estimación es apropiado para

todas las clases de software ni en todos los entornos de desarrollo. En consecuencia, los

resultados obtenidos a partir de tales modelos se deben emplear juiciosamente.

El modelo debe probarse mediante la aplicación de los datos recopilados a partir de proyectos

completados, colocar los datos en el modelo y luego comparar los resultados reales con los

predichos. Si la concordancia es insuficiente, el modelo debe afinarse y ponerse a prueba

nuevamente antes de que se pueda utilizar.

� El modelo COCOMO II

Este modelo introduce una jerarquía de modelos de estimación de software que lleva el

nombre de COCOMO por Modelo Constructivo de Costos. COCOMO ha evolucionado a un

modelo de estimación más amplio, llamado COCOMO II. Al igual que su predecesor, COCOMO

II es en realidad una jerarquía de modelos de estimación que aborda las áreas siguientes:

• Modelo de composición de la aplicación. Se emplean durante las primeras etapas de

la ingeniería del software, cuando son primordiales la elaboración de prototipos de las

interfaces de usuario, la consideración de la interacción del software y el sistema, la

valoración del desempeño y la evaluación de la madurez de la tecnología.

• Modelo de etapa de diseño temprano. Se utilizan una vez que se han estabilizado los

requisitos y se ha establecido la arquitectura básica del software.

• Modelo de etapa posterior a la arquitectura. Se emplea durante la construcción del

software.

� La ecuación del software

La ecuación de software es un modelo multivariable que supone una distribución específica

del esfuerzo a lo largo de la vida de un proyecto de desarrollo de software. El modelo procede

de datos de productividad recopilados de casi 4000 proyectos de software contemporáneos.

Con base en estos datos, un modelo de estimación de la forma

E = [LDC x B0.333 /P]3 x (1/t4)



Página 8 de 12

donde

E = esfuerzo en personas-mes o personas-año

t = duración del proyecto en meses o años

B = “factor especial de habilidades”

P = “parámetro de productividad” que refleja: madurez global del proceso y prácticas de

gestión, la medida en la que se emplean las buenas prácticas de ingeniería del software, el

nivel de los lenguajes de programación utilizados, el estado del entorno del software, las

habilidades y experiencias del equipo de software, y la complejidad de la aplicación.

Los valores típicos pueden ser P = 2000 para desarrollo del software anidado de tiempo real; P

= 10000 para software de telecomunicaciones y sistemas; P = 28000 para aplicaciones de

sistemas de negocios.

Investigadores sugieren un conjunto de ecuaciones derivables de la ecuación del software

para simplificar el proceso de estimación y emplear una forma más común para su modelo de

estimación. El tiempo mínimo de desarrollo se define como

tmin = 8.14(LDC/P)0.43 en meses para tmin>6 meses

E = 180Bt3 en personas-mes para E>=20 personas-mes

Al utilizar las ecuaciones anteriores con P=12000 (el valor recomendado para software

científico) para el software CAD estudiado previamente.

tmin = 8.14(33200/12000)0.43

tmin = 12.66 meses calendario

E = 180 x 0.28 x (1.05)3

E = 58 personas-mes

Calendarización de proyectos software

Aunque existen muchas razones por las cuales el software se entrega con retraso, la mayoría se

encuadra en una o más de las siguientes causas:

• Una fecha límite irrealizable establecida por alguien al grupo de ingeniería del software e

impuesta a los gestores y profesionales del grupo.

• Cambio en los requisitos del cliente que no se reflejan en modificaciones a la

calendarización.

• Riesgos predecibles o impredecibles que no se consideraron cuando comenzó el proyecto.



Página 9 de 12

• Dificultades técnicas que no pudieron preverse.

• Dificultades humanas imprevisibles.

• Falta de comunicación entre el personal del proyecto, lo que genera demoras.

Las actividades de estimación y las técnicas de calendarización se implementan atendiendo la

restricción de una fecha límite definida. Si las mejores estimaciones indican que la fecha límite es

irrealizable, un gestor de proyecto competente debe “proteger a su equipo de la presión excesiva

y devolver la presión a quienes la originan”.

Si el tiempo que los contratantes imponen para la entrega del software es diferente al tiempo

obtenido utilizando las técnicas de calendarización y estimación, se recomiendan los siguientes

pasos:

1. Realizar una estimación detallada empleando datos históricos de proyectos previos.

Determinar el esfuerzo y la duración estimados para el proyecto.

2. Aplicar un modelo de proceso incremental y desarrollar una estrategia de ingeniería de

software que entregará la funcionalidad crítica en la fecha límite impuesta, pero demorará

otra. Documente el plan.

3. Reunirse con el cliente y con la estimación detallada, explicarle por qué la fecha límite

impuesta es irrealizable.

4. Ofrezca la estrategia de desarrollo incremental con alternativa

La calendarización del proyecto de software es una actividad que distribuye estimaciones de

esfuerzo a través de la duración planificada del proyecto al asignar el esfuerzo a tareas específicas

de ingeniería del software. La calendarización evoluciona a lo largo del tiempo. Durante las

primeras etapas de la planificación del proyecto se desarrolla una calendarización macroscópica.

Este tipo de calendarización identifica las principales actividades del marco de trabajo del proceso

y las funciones de producto a las que se aplican. Conforme el proyecto trascurre, cada entrada en

la calendarización macroscópica se refina en una calendarización detallada. Aquí se identifican y

calendarización tareas específicas del software (requeridas para completar una actividad).

Definición de un conjunto de tareas para un proyecto de software

Ningún conjunto de tareas es apropiado por si solo para todos los proyectos. El conjunto de tareas

que sería apropiado para un sistema complejo y grande probablemente se apreciará como

demasiado destructivo para un producto de software pequeño y relativamente simple. En

consecuencia, un proceso de software eficaz debe definir una colección de conjuntos de tareas,

cada una diseñada para satisfacer las necesidades de diferentes tipos de proyectos.

El desarrollo de una calendarización del proyecto requiere distribuir un conjunto de tareas a lo

largo de la línea de tiempo del proyecto. El conjunto de tareas variará según el tipo de proyecto y

el grado de rigor con el que el equipo de software decide realizar su trabajo. Aunque es difícil



Página 10 de 12

desarrollar una taxonomía completa de tipos de proyectos de software, en la mayoría de las

organizaciones se encuentran los siguientes proyectos:

1. Proyectos de desarrollo del concepto, los cuales se inician para explotar algunas

aplicaciones o conceptos de negocios de alguna nueva tecnología.

2. Proyectos de desarrollo de nueva aplicaciones, los cuales se llevan a cabo como

consecuencia de una solicitud específica del cliente.

3. Proyectos de mejora de la aplicación, éstos ocurren cuando el software existente

experimenta grandes modificaciones en la función, el desempeño o las interfaces visibles

para el usuario final.

4. Proyectos de mantenimiento de aplicación, los cuales corrigen, adaptan o extienden el

software existente en formas que no sean obvias inmediatamente para el usuario final.

5. Proyectos de reingeniería, éstos se llevan a cabo con la finalidad de reconstruir un sistema

existente (heredados), en todo o en parte.

� Ejemplo de conjuntos de tareas

Las principales tareas de ingeniería del software descritas a continuación son aplicables a la

mayoría de los modelos de proceso. Como por ejemplo, considérese las tareas de ingeniería

del software para un proyecto de desarrollo del concepto.

1.1.1. La determinación del ámbito del concepto precisa el ámbito global del proyecto.

1.1.2. La planificación preliminar del concepto establece la habilidad de la organización

para acometer el trabajo que entraña el ámbito del proyecto.

1.1.3. La valoración del riesgo de la tecnología evalúa el riesgo asociado con la tecnología

que se implementará como parte del ámbito del proyecto.

1.1.4. La prueba del concepto demuestra la viabilidad de una nueva tecnología en el

contexto del software.

1.1.5. La implementación del concepto pone en práctica la representación del concepto en

una forma que pueda revisarla un cliente.

1.1.6. La reacción del cliente al concepto solicitada realimentación acerca de un concepto

de nueva tecnología y se dirige a aplicaciones específicas de los clientes.

� Refinamiento de las tareas principales

Las tareas principales descritas en la sección precedente se pueden utilizar para definir las

calendarización macroscópica de un proyecto. Sin embargo, esta calendarización se debe

refinar para crear una calendarización detallada del proyecto. El refinamiento comienza al

tomar cada tarea principal y descomponerla en un conjunto de subtareas.

Como ejemplo de descomposición de tarea, considérese la tarea 1.1, “determinación del

ámbito del concepto”:



Página 11 de 12

Definición tarea: Tarea 1.1 Determinación del ámbito del concepto

1.1.1. Identificar necesidades, beneficios y clientes potenciales:

1.1.2. Definir eventos de salida/control y entrada deseados que impulsen la aplicación:

Comienza Tarea 1.1.2

1.1.2.1. RTF (Revisión Técnica Formal): Revisar la descripción escrita de la necesidad.

1.1.2.2. Derivar una lista de salidas/entradas visibles al cliente.

1.1.2.3. RTF: Revisar salida/entradas con el cliente y modificar conforme se requiera

fintarea Tarea 1.1.2

1.1.3. Definir la funcionalidad/comportamiento para cada función principal:

Comienza Tarea 1.1.3

1.1.3.1. RTF: Revisar los objetos de datos de salida y entrada derivados en la tarea

1.1.3.2. Derivar un modelo funciones/comportamientos.

1.1.3.3. RTF: Revisar funcione/comportamientos con el cliente y modificar conforme se

requiera.

fintarea Tarea 1.1.3

1.1.4. Aislar aquellos elementos de la tecnología que se implementará en el software.

1.1.5. Disponibilidad de investigación del software existente.

1.1.6. Definir factibilidad técnica.

1.1.7. Realizar estimación rápida del tamaño.

1.1.8. Crear una definición del ámbito:

fintarea definición: Tarea 1.1

Una red de tareas, también denominada red de actividad, es una representación gráfica del flujo

de tareas en un proyecto. En ocasiones se utiliza como el mecanismo mediante el cual la secuencia

y dependencia de tareas son la entrada a una herramienta automatizada de calendarización del

proyecto.



Página 12 de 12

Es importante notar que la red mostrada es macroscópica. En una red de tareas detallada cada

actividad que muestra la figura se debe expandir. Por ejemplo, la tarea 1.1 se expandirá para

mostrar todas las tareas detalladas en el refinamiento.

Cronogramas.

Cuando se crea una calendarización de proyectos del software, el planificador comienza con un

conjunto de tareas. Si se emplean herramientas automatizadas, el análisis del trabajo se introduce

como una red de tareas o esbozo de tareas. Entonces se introduce el esfuerzo, la duración y la

fecha de inicio de cada tarea.

Como consecuencia de esta entrada, se genera un cronograma, también llamado gráfico Gantt. Es

posible desarrollar un cronograma para todo el proyecto. De manera alternativa, se pueden

desarrollar cronogramas separados para cada función del proyecto o para cada individuo que

trabaje en él.

La siguiente figura ilustra el formato de un cronograma. Todas las tareas del proyecto se citan en

la columna de la izquierda. Las barras horizontales indican la duración de cada tarea.

Cuando en el calendario se presentan al mismo tiempo múltiples barras, se implica la concurrencia

de la tarea. Los diamantes indican hitos.

estimación y calendarización para proyectos software. · estimaciÓn de tiempo y costo de...

Documents