Estimaciones de Software

ESTIMACIONES DE
SOFTWARE
Rogelio Francisco Ramírez Ramírez

[Email address]
Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su
autor. Registro de obra en trámite.
Contenido
1. Introducción ......................................................................................................................................................................... 2
2. Fundamentos ....................................................................................................................................................................... 3
2.1 Conceptos clave .............................................................................................................................................................. 3
2.2 Porque las palabras importan .......................................................................................................................................... 3
2.3 La crisis del software........................................................................................................................................................ 6
2.4 El software como negocio ................................................................................................................................................ 9
2.5 Bibliografía recomendada .............................................................................................................................................. 15
3. Estimaciones de software................................................................................................................................................. 16
3.1 Introducción ................................................................................................................................................................... 16
3.2 El tamaño del software................................................................................................................................................... 29
3.3 Clasificación de las estimaciones .................................................................................................................................. 32
3.4 Técnica de juicio de experto .......................................................................................................................................... 35
3.5 Técnica Delphi ............................................................................................................................................................... 36
3.6 Método de contar, calcular, juzgar ................................................................................................................................. 37
3.7 Método de análisis de puntos de función ....................................................................................................................... 38
3.8 Uso de información histórica para mejorar las estimaciones ......................................................................................... 47
4. Glosario .............................................................................................................................................................................. 52
5. Referencias ........................................................................................................................................................................ 58
1
1. Introducción
En el entorno mexicano actual, el desarrollo de software se ha vuelto un motor importante para el crecimiento de la economía
del país (Villalobos Hernández & Gutiérrez Tornés, 2001), (Secretaría de economía, 2012). El número de empresas que
desarrollan software creció en un 54% del 2002 al 2011 (Secretaría de economía, 2012) y hoy México ocupa ya el cuarto lugar
de importancia en desarrollo de software en el mundo (IVEX, 2007), (Secretaría de economía, 2012). Sin embargo, y a pesar
de este crecimiento, la industria del software en el país aún se encuentra en una etapa de poca madurez y en desarrollo (IVEX,
2007).
Aun cuando en nuestro país ya existen más de trescientas empresas que cuentan con una o más certificaciones en algún
modelo de procesos (Secretaría de economía, 2012) la realidad es que en el día a día muchos de los proyectos de software
fracasan (The Standish Group, 1995) o las empresas tienen que invertir grandes sumas económicas (The Standish Group,
1995) para mantener aplicaciones que no cumplen con los estándares de calidad necesarios.
De acuerdo a un estudio realizado por la ANIEI-ILCE1 con el apoyo de la Secretaría de Economía, para determinar la cantidad
y calidad de recursos humanos necesarios para el desarrollo de la industria del software en México (Secretaría de economía,
2012), se detectaron 2 problemáticas fundamentales:
 La disparidad que existe entre los conocimientos adquiridos en las instituciones educativas y las competencias
demandadas por la industria.
 El costoso y extenso período de transición adaptativa, esto es, el tiempo entre el egreso de las instituciones
educativas y el momento en que son productivos.
Por lo anterior, este curso fue diseñado con el objetivo de incrementar las habilidades profesionales de las personas que
participan en los procesos de software, a través de la aplicación de la ingeniería.
Si el objetivo anterior se cumple, se espera que la madurez de los procesos de software incremente en las empresas para
que así, puedan tener mayor eficiencia, empleados y clientes más satisfechos, para que por consecuencia obtengan mayores
ingresos. En la mayoría de las economías, cerca de una tercera parte del crecimiento del PIB real es atribuible a mejoras en
la eficiencia con la que se utilizan los insumos o factores de la producción (Secretaría de economía, 2012).
El presente trabajo representa una combinación de lecciones aprendidas y mejores prácticas ya implementadas y mejoradas
por equipos de desarrollo de software en México, además de información recopilada de diversas fuentes de información
respetadas y reconocidas en la industria del software en el mundo.
1 Asociación Nacional de Instituciones de Educación en Tecnologías de la Información, A.C. y el Instituto Latinoamericano de la Comunicación Educativa
2
2. Fundamentos
Tal como se mostrará más delante en este mismo documento, es importante comprender y distinguir los siguientes:
2.1 Conceptos clave
2.1.1 Software
Es el conjunto de programas de computadora, procedimientos, datos y documentación asociada pertenecientes a la operación

de un sistema computacional. (IEEE, 1990)
2.1.2 Programa de computadora
Una combinación de instrucciones de computadora y definiciones de datos que permiten al hardware de computadora llevar
a cabo funciones computacionales o de control. (IEEE, 1990)
2.1.3 Proyecto
Es un esfuerzo temporal realizado para crear un producto, servicio o resultado únicos. (PMI, 2008)
2.1.4 Proceso
Un conjunto definido de actividades o comportamientos llevados a cabo por humanos o máquinas para alcanzar uno o más
objetivos. (ABPMP, 2009)
Para mayor información acerca de estos conceptos ver el Glosario.
2.2 Porque las palabras importan

En nuestra industria es muy común que se empleen términos o conceptos, que tienen significados diferentes, de forma
indistinta, como si significaran lo mismo. Aparentemente podría no haber mayor problema con esto, pero conforme una
empresa madura sus procesos de software el lenguaje técnico y el significado de las palabras se vuelven relevantes para
mejorar la comunicación y, por lo tanto la efectividad y la eficiencia en la organización y sus proyectos.
2.2.1 Diferencia entre sistema, software, aplicación y programa
Uno de los elementos que más comúnmente es llamado de diferentes formas, aunque los nombres con los que se le llama
signifiquen cosas diferentes, es el software mismo. Para comprender las diferencias hay que comprender los significados de
cada palabra, de ahí entonces que es importante comprender primero que:
3
 Un sistema es un conjunto de cosas que relacionadas entre sí ordenadamente contribuyen a determinado objeto
(RAE, 2012), es decir, muchas cosas pueden ser un sistema, entre ellas el software, pero no es lo único.
 Luego entonces, se puede decir que un sistema computacional es un sistema que contiene una o más computadoras
y software asociado (IEEE, 1990), es decir, un sistema computacional no solamente está conformado por un
programa computacional.
 De lo anterior entonces es importante comprender que un programa computacional no necesariamente es igual a un
programa, es decir, un programa puede significar varias cosas (RAE, 2012), la mayoría de ellas no relacionadas con
la computación. Por otro lado, un programa computacional es una combinación de instrucciones de computadora y
definiciones de datos que permiten al hardware de computadora llevar a cabo funciones computacionales o de control
(IEEE, 1990).
 Por otro lado, el software es un conjunto, que está conformado por programas de computadora, procedimientos,
datos y documentación asociada pertenecientes a la operación de un sistema computacional (IEEE, 1990).
 Y finalmente, pero no por eso menos importante, una aplicación o software de aplicación es un software diseñado
para cumplir con necesidades específicas de un usuario, por ejemplo, software de nómina, recursos humanos o
ventas (IEEE, 1990).
2.2.2 Diferencia entre programa computacional y proyecto
Otra de las confusiones más comunes es la que se da cuando a un programa computacional se le llama proyecto. Aunque es
muy común que en otros ámbitos se emplee la palabra proyecto como sinónimo del producto, servicio o resultado que se está
generando, se considera que en la industria del software se vuelve relevante hacer la distinción para que el concepto de la
administración de proyectos se adopte más rápido y de forma más efectiva y eficiente. De lo anterior entonces se puede decir
que:
 Un proyecto es un esfuerzo temporal realizado para crear un producto, servicio o resultado únicos (PMI, 2008), es
decir, el proyecto, para el ámbito de este documento, es el conjunto de actividades que se realizan para crear un
programa computacional.
 Como ya se explicó antes, un programa computacional es una combinación de instrucciones de computadora y
definiciones de datos que permiten al hardware de computadora llevar a cabo funciones computacionales o de control
(IEEE, 1990).
2.2.3 Diferencia entre error, defecto y falla
Cuando se comienzan a medir los resultados obtenidos en procesos relacionados con la calidad del software se vuelve
relevante poder comprender la diferencia entre error, defecto y falla. De ahí que es importante que se comprenda que:
 Un error es una acción desacertada o equivocada (RAE, 2012) o una acción humana que produce un resultado
incorrecto (IEEE, 1990). Cuando un humano participa en el desarrollo de un producto y comete un error, puede
insertar un defecto en el producto.
4
 Por lo tanto, se puede decir que un defecto es una imperfección o deficiencia en un componente de un proyecto en
la cual dicho componente no cumple sus requerimientos o especificaciones y necesita ser corregido o reemplazado
(PMI, 2008).
 Finalmente, una falla es la acción y el efecto de que algo salga fallido, por ejemplo, el programa computacional.
En resumen se puede decir que, el humano (programador(a) de software) puede insertar defectos en el programa
computacional cuando comete errores. Posteriormente y debido a uno varios defectos, el programa computacional puede
fallar.
2.2.4 Diferencia entre costo y precio
Durante la administración de un proyecto es importante controlar los costos y, dependiendo de la organización que esté
ejecutando el proyecto, podría estar manejándose el precio en lugar del costo, de ahí la importancia de distinguirlos. Por lo
tanto:
 El costo es la cantidad que se da o se paga por algo (RAE, 2012), es decir, desde el punto de vista del que compra
o crea un proyecto o producto de forma interna, el costo es la cantidad pagada o invertida por dicho proyecto o
producto, aunque desde el punto de vista de quien vende, el costo representa lo que le cuesta ejecutar el proyecto
aunque después le agregue una utilidad y el total se convierta en el precio.
 Visto de otra forma, desde el punto de vista de quien vende un proyecto o producto y lo ofrece como un servicio a un
cliente, el precio representa lo que le cuesta ejecutar el proyecto más la ganancia que desea obtener por la venta de
dicho servicio (proyecto o producto). En este caso, desde el punto de vista de quien compra, lo que le cuesta el
proyecto representa un costo, como ya se mencionó anteriormente.
En resumen, el precio es la suma del costo más la utilidad. El costo puede descomponerse en varias cosas, sin embargo, esa
descomposición está fuera del alcance de este documento.
En la administración de un proyecto debe controlarse el costo, no el precio, ya que si se controla el precio se corre el riesgo
de tomar la utilidad como parte de la inversión disponible dentro del proyecto.
2.2.5 Diferencia entre duración y esfuerzo
Es muy común que en los proyectos se mida el esfuerzo en función del tiempo, por ejemplo, en horas, días o semanas. Lo
anterior puede provocar una confusión cuando existe comunicación relacionada con esfuerzo y duración, de tal forma que
durante una conversación o mensaje, una de las partes puede estar expresando algún valor en función del esfuerzo y la otra
parte podría interpretar dicho valor en función de la duración, por ejemplo: Juan le dice a María que realizar la actividad A le
tomará 16 horas y María podría interpretar que Juan realizará dicha actividad en 2 días, puesto que calcula 8 horas laborales
por día, sin embargo, quizá Juan contemplaba dedicar 4 horas diarias a dicha actividad, por lo que la duración en realidad
sería de 4 días y no 2, como lo pensó María. Si no existe la comunicación adecuada entre Juan y María, podría haber una
confusión importante posteriormente. La confusión anterior es muy común y de ahí que sea importante distinguir la diferencia
entre ambos conceptos. Por lo tanto:
5
 El esfuerzo es el número de unidades de trabajo requeridas para completar una actividad programada o un
componente de una estructura de desglose de trabajo. Usualmente expresado como horas/hombre, días/hombre o
semanas/hombre (PMI, 2008). El esfuerzo es igual a la duración de una actividad multiplicada por el número de
personas que participan en ella.
 La duración es el número total de periodos de trabajo (sin incluir días festivos u otros periodos no laborables)
requerido para completar una actividad programada o un componente de una estructura de desglose de trabajo.
Usualmente expresada como días o semanas laborables (PMI, 2008).
2.3 La crisis del software
2.3.1 Hacer software no es lo mismo que programar
Es muy común que quienes se gradúan de alguna carrera relacionada con las tecnologías de información y que eligen el
camino del software comiencen programando. También es muy común que quienes inician nuevas empresas de software sean
los mismos ingenieros o licenciados surgidos de las carreras de tecnologías de información y que alguna vez iniciaron
programando. Lo anterior ha provocado que muchas empresas de software enfoquen sus esfuerzos a la programación del
mismo, probablemente y, porque lo consideran necesario, también dediquen tiempo a la recopilación de los requerimientos
del software que van a desarrollar o mantener. Es muy probable que muchas de esas empresas comiencen con ninguna o
pocas prácticas de administración de proyectos, de arquitectura y diseño, de pruebas y qué pensar de prácticas de
aseguramiento de la calidad.
Por lo mencionado anteriormente es importante comprender que hacer software no es lo mismo que programar, es decir,
hacer software implica llevar a cabo, preferentemente de una forma estandarizada, actividades de estimaciones,
recopilación de requerimientos, arquitectura y diseño de software, pruebas de software, revisiones del código y la
documentación generada, administración de la configuración del software, administración de proyectos, medición
del desempeño, aseguramiento de la calidad entre otras, ah y por cierto, también de programación.
2.3.2 Reporte del caos
En el año de 1986 Fred Brooks publicó un ensayo titulado “No Silver Bullet — Essence and Accidents of Software Engineering”
en el cual argumentaba que: “no existe un solo desarrollo, en cualquier tecnología o técnica de administración, que por sí
misma prometa una mejora en al menos un orden de magnitud dentro de una década en productividad, confiabilidad o
simplicidad”. Y pareciera que Brooks tenía razón, pero su predicción pareciera aplicar no solamente para la siguiente década
después de que publicó su ensayo, sino que aparentemente sigue siendo válida hasta nuestros días.
En 1985 fue formado The Standish Group, con la visión de recolectar información de casos de la vida real de fallas y ambientes
de tecnologías de información. En 1995 este grupo publicó el reporte del caos en el cual, entre otros hallazgos, encontraron
que:
 El 31% de los proyectos sería cancelado antes de ser terminado. (The Standish Group, 1995)
6
 El 52.7% de los proyectos costarían 189% más que en sus estimaciones originales. (The Standish Group, 1995)
 La falla para producir software confiable para manejar las maletas en el aeropuerto de Denver le estaba costando a
la ciudad $1.1 millones de dólares por día. (The Standish Group, 1995)
 Las compañías estadounidenses y las agencias de gobierno gastarían $81 billones de dólares por proyectos de
software cancelados. Estas mismas compañías pagarían $59 billones de dólares adicionales por proyectos de
software que serán terminados pero excederán sus estimaciones originales de duración. (The Standish Group, 1995)
 El promedio de proyectos de software que fueron terminados a tiempo y dentro de su presupuesto fue de 16.2%, sin
embargo, en compañías grandes el número de proyectos terminados a tiempo y dentro de su presupuesto
representaba solamente el 9% del total. (The Standish Group, 1995)
 Los proyectos terminados por grandes compañías estadounidenses contenían solamente el 42% de las funciones y
características que fueron propuestas originalmente. Sin embargo, en compañías pequeñas este porcentaje era
diferente, un total de 78.4% de sus proyectos de software fueron entregados con al menos el 74.2% de sus funciones
y características originales. (The Standish Group, 1995)
En años recientes, el reporte del caos muestra que la ejecución de proyectos ha mejorado, pero no por mucho:
Tabla 1 Indicadores de proyectos de software de acuerdo al reporte del caos del Standish Group.
Proyectos 1994 1996 1998 2000 2002 2004 2006 2009
Exitosos 16% 27% 26% 28% 34% 29% 35% 32%
Desafiados 53% 33% 46% 49% 51% 53% 46% 44%
Fallidos 31% 40% 28% 23% 15% 18% 19% 24%
Fuente: (Domínguez, 2012)
Exitosos: terminaron a tiempo, dentro del presupuesto planeado y cumplieron los requerimientos de sus usuarios.
Desafiados: excedieron sus presupuestos, su duración planeada o no cumplieron completamente con las necesidades de
sus usuarios.
Fallidos: fueron cancelados y no terminaron.
Jim Johnson, presidente del Standish Group mencionó en el 2007 (Rubinstein, 2007) que la mejoría con respecto a años
anteriores principalmente se debió a:
 Mejor administración de proyectos

 Desarrollo iterativo
 Emergente infraestructura Web
7
2.3.3 Casos de estudio
2.3.3.1 Software de manejo de equipaje del aeropuerto de Denver

Originalmente facturado como el sistema más avanzado del mundo, el sistema de manejo de equipaje del nuevo aeropuerto
internacional de Denver se convirtió en uno de los más notorios ejemplos de proyectos fallidos.
Originalmente fue planeado para automatizar el manejo de equipaje a través del aeropuerto entero, el sistema probó ser más
complejo que lo que algunos creyeron originalmente. Los problemas para construir el sistema resultaron en una espera
en la apertura del nuevo aeropuerto de 16 meses mientras los ingenieros trabajaban para hacer que el sistema funcionara.
El retraso agregó aproximadamente $560 millones de dólares al costo del aeropuerto. Al final del día, el sistema que fue
finalmente implementado fue una sombra de lo que estaba originalmente planeado. En lugar de integrar las tres salas en un
sólo sistema, el sistema soportaba vuelos de salida solamente en una de las salas. Todo el equipaje adicional era manejado
por un remolcador manual y un sistema de carretillas que fue construido a la carrera cuando se hizo claro que el sistema
automatizado nunca cumpliría sus metas.
Inclusive la porción del sistema que fue implementada nunca funcionó apropiadamente y en agosto de 2005 el sistema fue
desechado por completo. El costo de un millón de dólares mensuales empleados para mantener el sistema fue contrarrestando
el valor que ofrecían las partes restantes del sistema además de que el uso de un sistema manual realmente ayudó a reducir
costos.
Los factores reportados a la prensa y que contribuyeron al fracaso fueron: subestimación de la complejidad, una arquitectura
compleja, cambios en los requerimientos, subestimación de la duración y el presupuesto, despido del consejo de expertos,
entre otros.
(Calleam Consulting Ltd, 2012)
2.3.3.2 El colapso de la red de AT&T

En 1990, 75 millones de llamadas de teléfono en todo Estados Unidos no fueron respondidas después de que un simple switch
en uno de los 114 centros de AT&T sufrió un problema mecánico menor, el cuál apagó todo el centro. Cuando el centro volvió
a funcionar, envió un mensaje a otros centros, lo cual provocó que se apagaran y resetearan.
El culpable resultó ser un error en una sola línea de código, nada de hackers como se especuló en aquel entonces, que había
sido agregada durante una actualización altamente compleja del software. American Airlines estimó que este pequeño error
le costó $200,000 dólares en reservaciones.
(Barker, 2007)
8
2.3.3.3 La explosión de Ariane 5

En 1996, el cohete de lanzamiento de satélites más nuevo y no tripulado, el Ariane 5, fue intencionalmente explotado apenas
algunos segundos después de haber despegado en su vuelo inaugural en Kouru, en la Guyana francesa. La agencia espacial
europea estimó que el desarrollo total de Ariane 5 costó más de 8 billones de dólares. A bordo había cuatro satélites científicos
con un costo de $500 millones de dólares creados para estudiar cómo el campo magnético de la tierra interactúa con los
vientos solares.
De acuerdo a una pieza en la revista New York Times, la autodestrucción fue disparada por el software que intentaba llenar
un espacio de 16 bits con un número de 64 bits.
"Este apagón ocurrió 36.7 segundos después del lanzamiento, cuando la computadora del sistema de navegación intentó
convertir un dato, el de la velocidad lateral del cohete, de un formato de 64 bits a un formato de 16 bits. El número era
demasiado grande y resultó en un error de sobre flujo (overflow). Cuando el sistema de navegación se apagó, pasó el control
a una unidad idéntica, redundante, la cual estaba ahí para proveer respaldo en caso de que hubiera alguna falla. Pero la
segunda unidad había fallado de forma idéntica unos milisegundos antes. ¿Y por qué no? estaba ejecutando el mismo
software." mencionó el artículo.
(Barker, 2007)
2.4 El software como negocio
2.4.1 Programar vs hacer dinero
Uno de los principales conflictos que existen en la industria del software es el que tiene que ver con la visión que tiene un
programador de software promedio y la que tiene un empresario, de software o de cualquier industria que emplee software.
Es muy común que una persona que recién egresa de una carrera relacionada con el software decida comenzar su carrera
profesional programando software y que inicialmente busque crecimiento profesional adquiriendo la mayor cantidad de
conocimiento técnico posible, por otro lado, el empresario promedio enfocará sus esfuerzos en la obtención de mayores
ingresos económicos. Aunque estas dos visiones no necesariamente son mutuamente excluyentes, al final de cuentas si
representan visiones diferentes que si no son alineadas pueden provocar insatisfacción a ambas partes.
Para explicar de una manera más detallada lo anterior se presentan algunos de los intereses comunes de cada parte. Es
importante aclarar que las siguientes listas no son estáticas y los intereses mostrados no son los únicos que existen e inclusive
es probable que ni siquiera representen los intereses más importantes de cada una de las partes:
Intereses de un programador de software:
 Adquisición de nuevo conocimiento técnico.

 Mayores ingresos económicos.
 Reconocimiento por su trabajo.
 Flexibilidad y libertad laboral.
9
o Entiéndase flexibilidad y libertad como la posibilidad de tener un horario flexible de trabajo, respeto por sus
estimaciones, comprensión de sus jefes del hecho de que como humanos no pueden estar sentados ocho
horas diarias programando y como la posibilidad de realizar otras actividades de esparcimiento en horas
laborales, entre otras.
 Trabajar en proyectos con nueva tecnología.
 Otros.
Intereses de un empresario:
 Incrementar ingresos.
 Reducir costos.
 Reducir riesgos de negocio.
 Satisfacer a clientes.
 Satisfacer a empleados.
 Mejorar procesos (optimizarlos).
 Mayor efectividad y eficiencia del negocio.
 Otros.
Como puede observarse, algunos de estos intereses pueden estar en conflicto, por ejemplo, mientras un programador de
software busca mayor flexibilidad y libertad en el trabajo, el empresario está ocupado por obtener mayor eficiencia, que implica
entre otras cosas, la posibilidad de optimizar al máximo los recursos disponibles, entre ellos las horas productivas de un
programador de software. Otro ejemplo es el que tiene que ver con el hecho de que los programadores buscan trabajar en
proyectos que involucren nueva tecnología, sin embargo, hacer esto incrementa los riesgos del negocio desde el momento
que la nueva tecnología puede no tener la madurez necesaria para ser empleada en nuevas aplicaciones de software.
En resumen y para finalizar esta sección, en la medida que los programadores de software comprendan que los programas
computacionales que generan tienen un impacto económico (positivo o negativo) importante en las empresas que los utilizan
y en la medida que el empresario que desarrolla o emplea software comprenda que el software es hecho por personas y no
por máquinas, la madurez de la industria del software incrementará y podrán tenerse programadores y empresarios más
satisfechos.
2.4.2 Desperdicio relacionado al software
En la industria de la manufactura es muy común escuchar de la implementación de prácticas de mejora continua, tales como
la administración de la calidad total, y esfuerzos de optimización de la producción asociados a conceptos como la manufactura
esbelta, reducción de defectos, administración de la capacidad de la producción entre otros. Muchos de estos conceptos o
filosofías han sido adoptados y adaptados de empresas japonesas de manufactura.
Aunque como ya se mencionó, dichas prácticas o filosofías han sido adoptadas ampliamente en empresas de manufactura,
no es muy común que dichas prácticas sean empleadas en empresas de servicios o productos de software. Efectivamente
dichas prácticas pueden ser adoptadas a empresas de servicios y específicamente empresas de software, un ejemplo de ello
10
es la emergente disciplina conocida como Lean IT, en la que el principal objetivo es la eliminación del desperdicio, desperdicio
entendido como el trabajo que no agrega valor a un producto o servicio (Wikipedia, 2012).
Lean IT promete identificar y erradicar el desperdicio que contribuye a un pobre servicio al cliente, pérdida de negocio, costos
de negocio más altos de lo necesario y pérdida de productividad de los empleados. Para estos fines, Lean IT se enfoca en
ocho elementos de la operación de TI que no agregan valor al producto, servicio terminado o a la organización que los genera:
Tabla 2 Objetivos de desperdicio en Lean IT
Desperdicio Ejemplo En qué se traduce en el negocio

Defectos No cumplimiento de un requerimiento Insatisfacción del cliente
Cálculo mal realizado por un programa computacional Costos adicionales de corrección
Sobreproducción (sobre Generación de características (funciones) adicionales Incremento en los costos de producción
aprovisionamiento) no solicitadas por el cliente.
Espera Tiempo que un equipo de desarrollo de software debe Costos no planeados (asociados al
esperar para instalar una aplicación cuando el servidor tiempo de espera, tiempo no
(hardware) requerido para hacerlo no está disponible. productivo)
No aprovechamiento de los recursos en

otros proyectos en los que pueden ser
productivos.
Procesamiento que no Recopilación manual de información para obtención de Incremento de costos para la
agrega valor indicadores de desempeño de un proyecto organización
No aprovechamiento de los recursos en

otras actividades que generen valor.
Transportación Tiempo de traslado empleado para visitar las oficinas No aprovechamiento de recursos en
de un cliente para recopilar requerimientos. actividades que generen valor
Posible incremento de costos (por

gastos de transportación)
Inventario Programadores de software que no están asignados a Costos devengados por la empresa
algún proyecto productivo. mientras no exista un cliente que
pague, a través de un proyecto, por las
horas disponibles de dichos
programadores.
Movimiento Asistencia a reuniones para llegar a acuerdos. Pérdida de productividad
11
Desplazamientos necesarios (para ir al baño, para

fumar, para conversar, etc.) para el esparcimiento
durante horas laborales.
Conocimiento no No existencia de una base de conocimiento Baja satisfacción con el trabajo

empleado Procesos no documentados Incremento en los costos de
Comisión de los mismos errores de forma recurrente mantenimiento y soporte
Fuente: (Wikipedia, 2012)
2.4.3 Costo y precio
Para empresas que ofrecen servicios relacionados con productos de software y que lo hacen a través de la ejecución de
proyectos es muy importante distinguir la diferencia entre costo y precio al momento de planear, monitorear y controlar sus
proyectos. Quizá lo anterior no sea tan relevante para empresas cuyos proyectos de software se ejecutan de manera interna,
es decir, no venden servicios relacionados con la ejecución de dichos proyectos.
 El costo es la cantidad que se da o se paga por algo (RAE, 2012). La definición anterior se establece desde el punto
de vista de quien compra, pero desde el punto de vista de quien vende se puede decir que el costo es lo que cuesta
ejecutar un proyecto.
 El precio representa lo que cuesta (el costo) ejecutar un proyecto más la ganancia que desea obtener por la venta
de dicho proyecto.
Al igual que la premisa que se emplea en México para el IVA (Impuesto al valor agregado) cuando se dice que el IVA solamente
se traslada y no le pertenece a quien lo cobra, podría pensarse del precio, es decir, la utilidad no le pertenece a un proyecto,
por lo tanto, cuando un proyecto que fue vendido se planea, monitorea y controla, solamente debe considerar el costo como
su presupuesto y no el precio, ya que este último incluye la utilidad.
Para mayor información de las diferencias entre el precio y el costo ver la sección Diferencia entre costo y precio en este
mismo documento.
2.4.4 Reducción de costos mediante la prevención
El siguiente texto fue tomado del libro Software Project Survival Guide. (McConnell, Software Project Survival Guide, 1998)
“Upstream, Downstream
Los buenos procesos de software están diseñados para resolver problemas de forma temprana en un proyecto. Este concepto
es lo suficientemente importante para discutirlo con algo de detalle.
12
Algunas veces habrás escuchado a los desarrolladores experimentados hablar acerca de las partes "upstream" (ir contra la
corriente) y "downstream" (ir en el sentido que va la corriente) de un proyecto. La palabra "upstream" simplemente se refiere
a las partes tempranas de un proyecto tales como el desarrollo de requerimientos y la arquitectura, mientras que "downstream"
se refiere a las últimas partes tales como construcción y pruebas del sistema.
He encontrado que esta distinción entre "upstream" y "downstream" es una forma fundamentalmente útil de pensar acerca de
un proyecto de software. El trabajo que los desarrolladores hacen en las etapas tempranas del proyecto es colocado en un
flujo y tiene que ser "pescado" más delante en el proyecto. Si el trabajo que se hizo al inicio es bien hecho, el trabajo que
es "pescado" más tarde es saludable y contribuye al éxito del proyecto. Si el trabajo que se hizo al inicio es hecho
pobremente, el trabajo que es "pescado" más tarde puede perjudicar severamente al proyecto. En circunstancias
extremas, inclusive puede evitar que el proyecto sea terminado.
Investigadores han encontrado que un defecto insertado en el flujo del proyecto de forma temprana, por ejemplo, un
defecto en la especificación de requerimientos o arquitectura, tiende a costar de 50 a 200 veces más para ser
corregido hacía el final del proyecto que si hubiera sido corregido lo más cercano al punto en el que fue originalmente
colocado en el flujo. La siguiente figura ilustra dicho efecto:
Ilustración 1 Costo de corrección de un defecto de acuerdo a la fase en que es corregido
Una sentencia en una especificación de requerimientos puede fácilmente convertirse en varios diagramas de diseño. Más
tarde en el proyecto, esos diagramas pueden convertirse en cientos de líneas de código fuente, docenas de casos de pruebas,
muchas páginas de documentación de usuario, pantallas de ayudas, instrucciones para el personal de soporte técnico, entre
otras.
13
Si el equipo del proyecto tiene una oportunidad de corregir una equivocación en la etapa en la que se están recolectando los
requerimientos, cuando el único trabajo que ha sido hecho es la creación de una sentencia de requerimientos, hace sentido
que el equipo corrija dicha sentencia en lugar de corregir todas las diferentes manifestaciones de dicha sentencia inadecuada
hacía el final del proyecto. Esta idea algunas veces es llamada "contención de fase" y se refiere a la detección y corrección
de los defectos en la misma fase en la cual los defectos fueron introducidos.
Puesto que ningún código fuente es generado mientras las actividades "upstream" son ejecutadas, dichas
actividades pueden hacer parecer que están retrasando "el verdadero trabajo" del proyecto. En realidad, están
haciendo exactamente lo contrario. Están estableciendo las bases para el éxito del proyecto.
Equivocarse del lado de demasiado proceso marginalmente incrementará la sobrecarga del proyecto, pero equivocarse del
lado de demasiado poco permite que los defectos se deslicen y entonces deberán ser corregidos con un costo de 50 a 200
veces mayor que el costo de corrección más eficiente. Por esta razón, el "dinero inteligente" reside del lado de demasiado
proceso en lugar del lado de muy poco.”
2.4.5 Costeo del software
Es muy común, al menos en la industria del software mexicana, que los costos de una aplicación de software sean establecidos
de acuerdo al número de horas invertidas en el desarrollo de dicha aplicación. Esta forma de costear las aplicaciones no
necesariamente es inadecuada, sin embargo, existe un método que permite estandarizar y comparar los costos de varias
aplicaciones y que es independiente de la complejidad de cada aplicación, a diferencia del costeo por horas que no
necesariamente es efectivo cuando se trata de hacer comparaciones, ya que la complejidad entre las diferentes aplicaciones
que se están comparando varía. Dicho método está relacionado con la medición del tamaño del software.
Es muy común también que cuando se realizan estimaciones en un proyecto de software se estime la duración, el esfuerzo 2
y el costo de dicho proyecto con base en el esfuerzo que debe realizarse en cada actividad del proyecto, sin embargo, pocas
veces se estima el tamaño del software. Estimar el tamaño del software permite estimar también la duración, el esfuerzo y el
costo de un proyecto y se pueden calcular con base en la duración, esfuerzo y costo que deben invertirse para generar una
unidad de software. Una unidad de software es la unidad de medida del tamaño de software, las unidades de medida del
tamaño del software más comunes son los puntos de función y las líneas de código.
Entonces, para poder costear el software con base en su tamaño se requiere primero estimar el tamaño del software y
posteriormente establecer la duración, esfuerzo y costo unitario de cada unidad de tamaño. Existen diferentes métodos para
medir el tamaño del software, uno de los más aceptados y reconocido como estándar a nivel mundial es el análisis de puntos
de función (IFPUG, 2012).
Para comprender mejor el concepto del tamaño del software vea la sección Tamaño del software en este mismo documento.
2 Entiéndase esfuerzo como el número de horas, días, meses o años que se requieren para realizar una actividad, multiplicados por el número de personas que participan en dicha
actividad.
14
2.5 Bibliografía recomendada

Ver Referencias.
15
3. Estimaciones de software
3.1 Introducción
“Es muy difícil defender una estimación de forma vigorosa, plausible y arriesgando el trabajo cuando ésta fue derivada por un
método no cuantitativo, soportada con muy pocos datos y certificada principalmente por las corazonadas de los gerentes”.
-Fred Brooks
3.1.1 ¿Qué es una estimación?
Existen diferentes definiciones de estimación, a continuación se presentan algunas:
1. Una evaluación tentativa o cálculo bruto (McConnell, Software Estimation (Demystifying the Black Art), 2006).
2. Un cálculo preliminar del costo de un proyecto (McConnell, Software Estimation (Demystifying the Black Art), 2006).
3. Aprecio y valor que se da y en que se tasa y considera algo (RAE, 2012).
4. Una evaluación cuantitativa de la probable cantidad o salida. Usualmente aplicada a los costos del proyecto, recursos,
esfuerzo y duraciones. Siempre debe incluir alguna indicación de precisión (ej. +- x por ciento) (PMI, 2008).
Es muy importante recalcar que una estimación siempre será una aproximación, no un dato exacto.
3.1.2 Empleo y utilidad de una estimación
Las estimaciones pueden emplearse y ser útiles para diferentes actividades durante un proyecto y en una organización:
 En proyectos:
o Para determinar el tamaño del software que se va a construir o modificar.
o Para determinar la duración del proyecto.
o Para determinar el esfuerzo que requieren las actividades del proyecto.
o Para determinar el costo del proyecto.
o Para determinar la cantidad de recursos, humanos y materiales, necesarios para el proyecto.
o Para determinar el avance de la aplicación, en términos de cuánto software se ha construido.
o Para determinar parte del tamaño del proyecto.
o Para determinar parte del avance del proyecto, en función del avance de la aplicación.
o Para determinar la cantidad de defectos que se han encontrado o que pueden llegar a encontrarse en la
aplicación.
 En una organización:
o Para poder comparar aplicaciones.
o Para poder comparar proyectos.
o Para determinar la productividad de los desarrolladores del software.
o Para establecer precios de venta del software.
16
o Para comparar las cotizaciones de proyectos de desarrollo de software de diferentes proveedores.
3.1.3 Diferencia entre estimar y planear
Es muy común que en la industria del software se confunda el concepto de estimación por el de programación (de actividades),
es decir, cuando se solicita una estimación algunas personas elaboran un cronograma de las actividades que se van a realizar.
Aunque elaborar un cronograma de actividades para posteriormente asignar esfuerzo, costo o duración es una forma de
estimar, la programación de actividades es más una actividad de planeación y no es la única forma de estimar.
Por lo anterior, es importante distinguir claramente las principales diferencias entre una planeación y una estimación:
 Planeación
o Prever el futuro,
o Escritura en que sumariamente se precisan los detalles para realizar una obra.
 Estimación
o Aproximación,
o Evaluación tentativa,
o Cálculo bruto,
o Cálculo preliminar,
o Evaluación cuantitativa.
La estimación y la planeación son tópicos relacionados, pero estimar no es planear y planear no es estimar. La estimación
debe ser tratada como un proceso imparcial y analítico; la planeación debe ser tratada como un proceso parcial que busca
alcanzar objetivos. Con la estimación, es peligroso querer que el estimado salga ante cualquier respuesta particular. La meta
es la precisión; la meta no es buscar un resultado particular. Pero la meta de la planeación es buscar un resultado particular.
Deliberada y apropiadamente parcializamos nuestros planes para conseguir salidas específicas. Planeamos significados
específicos para alcanzar un fin específico.
Los estimados forman la base para los planes, pero los planes no tienen que ser los mismos que los estimados. Si los
estimados son dramáticamente diferentes de los objetivos, los planes del proyecto necesitan reconocer esas diferencias y
atenderlas con un alto nivel de riesgo. Si los estimados son cercanos a los objetivos, entonces los planes pueden asumir
menos riesgo.
En conclusión, estimar puede ser una actividad de planeación, estimar es calcular algún valor necesario para la planeación o
para la toma de alguna decisión, valor tal como el esfuerzo, costo, duración o tamaño (del software). Mientras que planear
consiste en establecer las estrategias, actividades, objetivos, recursos, procesos, etc. de forma anticipada con la intención de
actuar a futuro acorde a lo definido.
17
3.1.3.1 La relación entre las estimaciones y la planeación
Planeación de proyectos
1.1 Establezca el alcance de la aplicación 1.2 Estime el tamaño de la aplicación
1.3 Defina los procesos que seguirá 1.4 Seleccione un ciclo de vida
1.5 Estime el esfuerzo requerido 1.6 Identifique los recursos necesarios
1.7 Identifique capacitación requerida, entregables, hitos, involucrados, responsabilidades, restricciones y

riesgos
1.8 Estime la duración del proyecto 1.9 Establezca el costo de la aplicación
18
3.1.4 Diferencia entre estimación, objetivo, compromiso
Estrictamente hablando, la definición del diccionario de estimación es correcta: una estimación es una predicción de cuánto
durará un proyecto o cuánto costará. Pero la estimación en los proyectos de software interactúa con objetivos de negocio,
compromisos y el control.
Un objetivo es un enunciado de un objetivo de negocio deseable.
Las empresas tienen razones importantes para establecer objetivos independientemente de las estimaciones de software.
Pero el hecho de que un objetivo es deseable o incluso aún, obligatorio, esto no necesariamente significa que es alcanzable.
Mientras que un objetivo es una descripción de un objetivo de negocio deseable, un compromiso es una promesa para entregar
una funcionalidad deseada con un nivel específico de calidad en una cierta fecha. Un compromiso puede ser lo mismo que un
estimado, o puede ser más agresivo o más conservador que el estimado. En otras palabras, no supongas que el compromiso
tiene que ser lo mismo que el estimado; no lo es.
3.1.5 El cono de la incertidumbre
El desarrollo de software consiste en realizar literalmente cientos de decisiones acerca de todos los temas relacionados con
las características del mismo. La incertidumbre en una estimación de software resulta de la incertidumbre de cómo se
resolverán las decisiones tomadas. Conforme se toman un gran porcentaje de dichas decisiones, se reduce la incertidumbre
de la estimación.
Como un resultado de este proceso de resolución de decisiones, los investigadores han encontrado que las estimaciones de
proyecto están sujetos a cantidades predecibles de incertidumbre en varias etapas. El cono de la incertidumbre muestra como
las estimaciones se vuelven más precisas conforme el proyecto avanza.
19
Ilustración 2 - El cono de la incertidumbre basado en hitos comunes de proyecto.
El eje horizontal contiene hitos comunes de proyecto, tales como el concepto inicial, la definición aprobada del producto, los
requerimientos completos, entre otros. Debido a sus orígenes, esta terminología suena de alguna forma orientada a productos.
La “definición de producto” se refiere simplemente a la visión acordada del software, o el concepto de software, y aplica
igualmente a servicios web, sistemas de negocio internos y la mayoría de tipos de proyectos de software.
El eje vertical contiene el grado de error que ha sido encontrado en estimaciones creadas por estimadores habilidosos en
varios puntos del proyecto. Las estimaciones podrían ser por cuánto costará una característica particular y cuánto esfuerzo
será requerido para entregar el conjunto de características, o podría ser por cuántas características pueden ser entregadas
para una cantidad particular de esfuerzo o tiempo.
Como se puede observar en la gráfica, las estimaciones creadas muy temprano en el proyecto están sujetas a un alto grado
de error. Las estimaciones creadas en el tiempo del concepto inicial pueden ser imprecisas por un factor de 4x en el extremo
más alto o 4x en el extremo más bajo (también expresada como 0.25x, que es simplemente 1 dividido entre 4). El rango total
de estimación del extremo alto al bajo es 4x dividido entre 0.25x, o 16X.
Una pregunta que los gerentes y los clientes se hacen es: "¿Si te doy otra semana de trabajo en tu estimación, puedes refinarla
para que contenga menos incertidumbre?” Esa es una pregunta razonable, pero desafortunadamente no es posible cumplir
esa petición. Investigaciones realizadas por Luiz Laranjeira sugieren que la precisión de la estimación de software depende
del nivel de refinamiento de la definición del software (Laranjeira, 1990). Entre más refinada sea la definición, más precisa
será la estimación, La razón por la que una estimación contiene variabilidad es que el proyecto de software en sí mismo
contiene variabilidad. La única forma de reducir la variabilidad en la estimación es reducir la variabilidad en el proyecto.
20
Una implicación engañosa de esta representación común del cono de la incertidumbre es que parece que tomará para siempre
que el cono adelgace – como si no se pudiera tener una muy buena precisión en la estimación hasta que el proyecto esté casi
terminado. Afortunadamente, esa impresión es creada porque los hitos en el eje horizontal están igualmente espaciado y
naturalmente suponemos que el eje horizontal es tiempo de calendario.
En realidad, los hitos enlistados tienden a estar cargados al frente en el cronograma del proyecto. Cuando el cono es re-
dibujado sobre una base de tiempo calendario, se parece a la siguiente figura:
Ilustración 3 - El cono de la incertidumbre basado en tiempo calendario. El cono se adelgaza mucho más rápido que en la
representación previa mostrada.
Como se puede observar en esta versión del cono, la precisión de la estimación mejora rápidamente para el primer 30% del
proyecto, mejorando de +-4x a +-1.25x.
Un concepto importante, y difícil, es que el cono de la incertidumbre representa la mejor precisión que es posible tener en
estimaciones de software en diferentes puntos del proyecto. El cono representa el error en estimaciones creadas por
estimadores habilidosos. Es fácilmente posible estimar de peor forma. No es posible ser más preciso; solamente es posible
tener más suerte.
3.1.5.1 El cono no adelgaza por sí mismo

Otra forma en la cual el cono de la incertidumbre representa el mejor caso en una estimación es que si el proyecto no está
bien controlado, o si los estimadores no son muy hábiles, las estimaciones no podrán mejorar. La siguiente figura muestra lo
que pasa cuando el proyecto no se enfoca en reducir la variabilidad – la incertidumbre no es un cono, sino una nube que
persiste hasta el final del proyecto. El problema no es realmente que las estimaciones no converjan; el problema es que el
proyecto en sí mismo no converge – esto es, no expulsa suficiente variabilidad para soportar más estimaciones precisas.
21
Ilustración 4 - Si un proyecto no es bien controlado o bien estimado, se puede terminar con una nube de incertidumbre que
contiene aún más error de estimación que el representado por el cono.
El cono adelgaza solo si se toman las decisiones que eliminan la variabilidad. Como lo muestra la figura siguiente, definir la
visión del producto (incluyendo el compromiso de lo que no se hará) reduce la variabilidad. Definir los requerimientos –
nuevamente, incluyendo lo que no se va a hacer – elimina la variabilidad posterior. Diseñar la interfaz de usuario ayuda a
reducir el riesgo de creciente variabilidad por requerimientos mal comprendidos. Por supuesto, si el producto no está realmente
definido, o si la definición del producto se redefine más adelante, el cono se hará más ancho y la precisión de la estimación
será más pobre.
Ilustración 5 - El cono de la incertidumbre no adelgaza por sí mismo. Se adelgaza tomando decisiones que remuevan las
fuentes de variabilidad del proyecto.
22
3.1.5.2 Consideraciones para el cono de incertidumbre en las estimaciones de software

Estudios de estimaciones de software han encontrado que los estimadores que inician con estimaciones de un solo punto y
crean rangos basados en sus números originales de un solo punto usualmente no ajustan sus valores mínimos y máximos lo
suficiente como para contabilizar la incertidumbre en sus estimaciones, especialmente en circunstancias que contienen alta
incertidumbre. Esta tendencia a usar rangos que son muy angostos puede ser atendida de dos maneras. La primera es
comenzar con una estimación de “lo más probable” y luego computar los rangos usando multiplicadores predefinidos, tal como
se muestra en la siguiente tabla:
Tabla 3 - Error de estimación por actividad de desarrollo de software
Error de alcance
Error posible en el Error posible en el Rango de estimaciones

Fase lado inferior lado superior inferiores y superiores
Concepto inicial 0.25x (-75%) 4x (+300%) 16x
Definición del producto aprobada 0.50x (-50%) 2x (+100%) 4x
Requerimientos completos 0.67x (-33%) 1.5x (+50%) 2.25x
Diseño de interfaz de usuario completo 0.80x (-20%) 1.25x (+25%) 1.6x
Diseño detallado completo (para proyectos

0.90x (-10%) 1.10x (+10%) 1.2x
secuenciales)
Fuente: Adaptado de Software Estimation with Cocomo II (Boehm, 2000).
Si se usan los valores de esta tabla, debe reconocerse que en el punto en el que se crea la estimación se desconoce si la
salida actual del proyecto caerá en el límite superior o en el límite inferior del rango.
Una segunda estrategia está basada en el hallazgo de que la habilidad para “saber cuánto” y la habilidad para “saber qué tan
incierto” son dos habilidades diferentes. Se puede tener una persona que estime el mejor y peor caso del rango y una segunda
persona que estime la probabilidad de que el resultado actual caiga en dicho rango.
3.1.5.3 Relación entre el cono de incertidumbre y el compromiso

Las organizaciones de software rutinariamente sabotean sus propios proyectos haciendo compromisos demasiado pronto en
el cono de incertidumbre. Si se realiza un compromiso en las fases del concepto inicial o la definición del producto, se tendrá
un factor de error de 2x a 4x en las estimaciones. Un administrador de proyectos habilidoso puede navegar el proyecto hasta
terminarlo si la estimación está dentro del 20% de la realidad del proyecto. Pero ningún administrador puede llevar a buen
puerto un proyecto cuando las estimaciones son erróneas por un porcentaje de cientos.
23
No es posible realizar compromisos significativos en la parte temprana y ancha del cono. Las organizaciones efectivas
retrasan sus compromisos hasta que han realizado el trabajo necesario para forzar que el cono se haga más angosto. Los
compromisos significativos en la parte media del proyecto (cerca del 30% del camino recorrido) son posibles y apropiados.
3.1.5.4 El cono de la incertidumbre y el desarrollo iterativo

El cono de incertidumbre está más relacionado con proyectos iterativos que lo que puede estar con proyectos secuenciales.
Si se está trabajando en un proyecto que realiza un ciclo completo de desarrollo en cada iteración se tendrá un cono “miniatura”
en cada iteración. Antes de que se realice el trabajo de requerimientos para la iteración, se estará en el punto de la definición
del producto aprobada en el cono, sujeto a una variabilidad de 4x en las estimaciones del extremo bajo al alto del cono. Con
iteraciones cortas (menos de un mes), se puede mover de la definición del producto aprobada a los requerimientos completos
y diseño terminado de interfaz de usuarios en unos pocos días, reduciendo la variabilidad de 4x a 1.6x. Si el cronograma es
inmovible, la variabilidad de 1.6x aplicará para las características que se pueden entregar en el tiempo disponible, en lugar
del esfuerzo o duración.
Lo que se sacrifica con estrategias que dejan los requerimientos sin definir hasta el inicio de cada iteración es la certeza y
precisión acerca de la combinación de costo, duración y características que se entregarán en las iteraciones que están por
delante.
La alternativa a iteración total no es no tener iteraciones. Se ha encontrado que es casi universalmente inefectiva. Las
alternativas son menos iteraciones o diferentes iteraciones.
Muchos equipos de desarrollo han encontrado un término medio en el cual la mayoría de los requerimientos son definidos al
inicio del proyecto, pero el diseño, la construcción, pruebas y liberación son llevados a cabo en cortas iteraciones. En otras
palabras, el proyecto se mueve secuencialmente a través del hito de diseño terminado de interfaz de usuario (cerca del 30%
del tiempo del calendario del proyecto) y luego se cambian a una estrategia iterativa desde ese punto en delante. Esto reduce
la variabilidad existente en el cono cerca de +-25%, lo que permite controlar el proyecto lo suficiente para conseguir el objetivo
mientras se obtienen beneficios del desarrollo iterativo. Los equipos de proyecto pueden dejar alguna cantidad de tiempo
planeado para requerimientos por definir al final del proyecto. Lo anterior introduce algo de variabilidad relacionada con el
conjunto de funciones, lo cual, en este caso, es positivo porque se empleará solamente si se identifican funciones deseables
para implementar. Este término medio soporta un amplio rango de predictibilidad de costo y duración así como una cantidad
moderada de flexibilidad en requerimientos.
3.1.6 Las estimaciones y el control de proyectos
Algunas veces cuando la gente discute la estimación de software se trata a la estimación como una actividad puramente
predictiva. La gente se comporta como si el estimado fuera hecho por un estimador imparcial, sentado en algún lugar en el
espacio exterior, desconectado de la planeación del proyecto y la priorización de actividades.
24
En realidad, hay muy poco de pureza en una estimación de software. Si alguna vez ha querido un ejemplo del principio de
incertidumbre de Heisenberg aplicado a software, sería la estimación. El principio de incertidumbre de Heisenberg es la idea
de que el mero acto de observar una cosa la cambia, de tal forma que nunca se estará seguro de cómo se hubiera comportado
esa cosa si no se le hubiere estado observando). Una vez que hacemos una estimación y, sobre las bases de dicho estimado,
hacemos un compromiso para entregar funcionalidad y calidad en una fecha determinada, entonces controlamos el proyecto
para alcanzar el objetivo. Las actividades típicas de control del proyecto incluyen la remoción de requerimientos no críticos, la
redefinición de requerimientos, el reemplazo de personal menos experimentado con personal más experimentado, entre otras.
La siguiente figura ilustra dicha dinámica:
Además de las actividades de control del proyecto, los proyectos a menudo son afectados por eventos externos imprevistos.
El equipo del proyecto podría necesitar crear una liberación intermedia para soportar u cliente clave. El personal podría ser
distraído para soportar una aplicación antigua, entre otras cosas.
Los eventos que ocurren durante un proyecto casi siempre invalidan las suposiciones que fueron empleadas para estimar el
proyecto. Las suposiciones de funcionalidad cambian, las suposiciones de personal cambian y las prioridades cambian. Se
vuelve imposible realizar una evaluación analítica clara de si el proyecto fue estimado de forma precisa, puesto que el proyecto
de software que ha sido entregado no es el proyecto que fue originalmente estimado.
En la práctica, si se entrega un proyecto con el nivel de funcionalidad esperado, usando el nivel de recursos planeado, dentro
del tiempo establecido, entonces típicamente se dice que el proyecto “cumple sus estimados”, a pesar de todas las impurezas
analíticas implícitas en dicho enunciado.
3.1.7 Factores a considerar al realizar estimaciones
Al igual que los ciclos de vida del software, los modelos de procesos y metodologías, la elaboración de una estimación siempre
dependerá del contexto, por lo tanto, siempre será recomendable adaptar cualquier proceso, técnica o método de estimación
25
a la situación particular en la que se empleará. Lo anterior significa que es importante tener claro cuál es el propósito de la
estimación, en qué etapa se está realizando, quien o quienes la están elaborando, con qué información se cuenta y qué otros
procesos dependen de la información que se generará.
Algunos proyectos determinan sus características y luego se enfocan en estimar la duración y el esfuerzo requeridos para
entregar dichas características. Otros proyectos determinan sus presupuestos y tiempo de desarrollo y luego se enfocan en
cuántas características pueden entregar.
Muchas técnicas de estimación son aplicables independientemente de lo que se está estimando; algunas pocas técnicas
funcionan mejor para estimar cuánto esfuerzo requerirá un proyecto, cuánto durará un proyecto o cuántas características
pueden ser entregadas.
Al seleccionar un proceso, técnica o método de estimación deben considerarse los siguientes factores:
3.1.7.1 El tamaño del proyecto

El tamaño del proyecto es un factor importante a considerar al elegir una técnica o método de estimación. Debido a que el
dimensionamiento de un proyecto puede variar dependiendo de cada compañía, grupo o persona, en este documento no se
establecen nombres o definiciones puntuales de tamaño, sin embargo, los siguientes son algunos de los criterios que pueden
considerarse para establecer el tamaño de un proyecto y que finalmente tendrán influencia en la decisión de la mejor técnica
o método de estimación:
 Duración del proyecto

 Número de personas que conformarán el equipo del proyecto
 Tamaño del software que se va a construir o modificar.
 Propósito del proyecto, es decir, crear un nuevo programa computacional o modificar uno existente.
3.1.7.2 La forma de medir el tamaño de la aplicación

La forma en que se mida el tamaño de la aplicación tendrá influencia importante en la decisión de qué método o técnica debe
emplearse para estimar, lo anterior debido a que diferentes métodos y técnicas aplican para diferentes unidades de medida
del tamaño, por ejemplo, el método de análisis de puntos de función se emplea para medir las funciones que realizará la
aplicación y no puede ser empleado para contar o estimar el número de líneas de código de la misma.
3.1.7.3 El ciclo de vida

Es muy común que en los proyectos de software se realicen estimaciones al inicio del proyecto, o previo al inicio del proyecto,
sin embargo es importante que durante el proyecto se realicen estimaciones que permitan ir incrementando la certidumbre de
la duración, costos, esfuerzo y tamaño originalmente estimados. Por lo anterior, es importante que, dependiendo del ciclo de
vida seleccionado se determine cuántas estimaciones se realizarán y qué métodos o técnicas se emplearán en cada etapa.
26
3.1.7.4 El propósito del proyecto

El propósito del proyecto es uno de los factores más importantes a considerar al estimar, para términos de este documento
se identifican los siguientes propósitos genéricos para un proyecto de software:
 Desarrollar una nueva aplicación (nuevo desarrollo)

 Modificar una aplicación existente (mantenimiento)
 Implementación de una aplicación (instalación y configuración de la aplicación)
 Migración de una aplicación (movimiento de la aplicación de un ambiente a otro)
 Actualización de una aplicación (actualización de la aplicación de una versión a otra más nueva)
En cada uno de los casos anteriores el método o técnica de estimación puede, y debe, variar. Por ejemplo, muy probablemente
una estimación de proyecto en los dos primeros casos esté basada en el tamaño de lo que se va a construir, sin embargo, en
los tres últimos casos (implementación, migración y actualización) la estimación tenga que estar basada en los entregables
del proyecto y las actividades que deben realizarse para instalarlos, diseñarlos, construirlos, configurarlos o probarlos.
3.1.7.5 La tecnología empleada

La tecnología empleada siempre será un factor importante a considerar sobre todo si se toma en cuenta que la selección de
ésta puede facilitar o hacer más complejo el diseño, la construcción, las pruebas o la liberación de la aplicación. Las decisiones
arquitectónicas relacionadas con la tecnología siempre afectarán a la aplicación y al proyecto mismo, ya sea generando más
problemas que deben resolverse o reduciéndolos.
3.1.8 El proceso de estimar
Es importante comprender que cuando se realiza una estimación, las actividades asociadas a ésta se realizan como parte de
procesos o funciones de negocio que integran varios procesos. Siendo así, elaborar una estimación requerirá elementos de
entrada (insumos) y generará productos (salidas) que probablemente sean requeridos para otros procesos. En dicho contexto
se presenta el siguiente:
3.1.8.1 Proceso de estimación

A continuación se presenta un proceso de estimación propuesto, este proceso puede, y muy seguramente debe, ser
adaptado a las necesidades particulares de cada organización:
Insumos (entradas) Actividades Productos
- Alcance de la aplicación 1. Identificar el propósito de la estimación Estimación:

2. Identificar el propósito del proyecto - Tamaño
3. Identificar el tamaño del proyecto
27
- Requerimientos de la 4. Identificar el ciclo de vida - Duración

aplicación 5. Identificar la tecnología - Esfuerzo
- Restricciones de la 6. Seleccionar una o varias técnicas o métodos de estimación
- Costo
aplicación y/o del proyecto 7. Adaptar la(s) técnica(s) o método(s) de estimación (en caso de ser
necesario) seleccionado(s) - Precio
8. Aplicar la(s) técnica(s) o método(s) de estimación seleccionado(s) y - Recursos

adaptado(s)
9. Validar la estimación
Herramientas
- Técnicas de estimación
- Métodos de estimación
- Información histórica
- Software de estimación
Roles
Estimador
El siguiente diagrama presenta algunos de los componentes del proceso de estimación.
Ilustración 6 – Algunos de los componentes del proceso de estimación
28
3.2 El tamaño del software
3.2.1 Introducción
En la industria de software mexicana es muy común hablar de la duración de un proyecto o de una actividad, inclusive se han
generalizado los conceptos de esfuerzo y costo, sin embargo, aunque estos parámetros son válidos y están relacionados con
las estimaciones de proyectos, podrían no ser muy útiles en proyectos de software si se estiman y emplean de forma aislada
sin considerar el tamaño del software que se va a construir.
¿Pero a qué se refiere entonces el tamaño de software y qué relación tiene con las estimaciones? El tamaño de software es
el atributo que permite determinar cuánto mide éste. Dicho atributo está estrechamente ligado con las estimaciones puesto
que representa la entrada principal requerida para determinar el esfuerzo, duración y costo de diseñarlo, construirlo, probarlo
y liberarlo.
Dado que el software es un bien intangible, puede llegar a ser complicado determinar cuál es su tamaño. Las dos unidades
de medida más comunes, generalmente empleadas y aceptadas para medir el tamaño del software son:
 Las líneas de código

 Los puntos de función, que no se refiere a otra cosa más que a las funciones del software.
Identificar el tamaño del software a través de cada una de estas unidades de medida tiene sus ventajas y desventajas, sin
embargo, si una organización logra estandarizar el método y la unidad de medida empleada para determinar el tamaño del
software a través de sus proyectos, la unidad de medida en sí misma será menos relevante que la información que podrá
obtenerse y que podrá ser de gran utilidad para estimar proyectos futuros, aplicaciones futuras, aplicaciones compradas,
productividad de los desarrolladores de software, entre otras cosas.
El tamaño del producto es el más grande contribuyente en el cronograma de un desarrollo. Los productos más grandes toman
más tiempo. Los productos más pequeños toman menos tiempo. Características adicionales requieren especificación, diseño,
construcción, pruebas e integración adicionales. Requieren coordinación adicional con otras características y requieren que
se coordinen otras características con ellas. Puesto que el esfuerzo requerido para construir software se incrementa
desproporcionadamente más rápido que el tamaño del software, una reducción en tamaño mejorará la velocidad de desarrollo
desproporcionadamente. Reducir el tamaño de un programa de tamaño medio a la mitad típicamente reducirá el esfuerzo
requerido en casi dos tercios.
Se puede reducir el tamaño del producto dejando para desarrollo solamente las características esenciales o se puede reducir
temporalmente desarrollando un producto en etapas. También se puede reducir desarrollando en un lenguaje o herramienta
de alto nivel de tal forma que cada característica requiera menos código.
29
3.2.2 Los componentes del software
Ya se habló del tamaño del software y cómo puede medirse, sin embargo, es muy importante comprender que no siempre los
métodos o modelos empleados por la mayoría funcionan para todo y para todos. Por lo anterior, es muy importante tener muy
claro cuáles son los componentes del software para que, en caso de ser necesario, puedan establecerse nuevos métodos de
medición del tamaño que funcionen para las necesidades de cada organización.
Dicho lo anterior, podríamos decir que los siguientes son algunos de los componentes más comunes e importante del software,
entendiendo software como un sistema compuesto por una aplicación y su documentación. El siguiente modelo, aunque es
extenso, no es limitativo:
Software
Aplicación Documentación
De
Pantallas Componentes Base de datos Archivos
requerimientos
Controles Clases Tablas De datos De arquitectura
Etiquetas Métodos Campos De configuración De diseño
Atributos Registros De pruebas
Variables Índices De liberación
Procedimientos
Constantes De usuario
almancenados
Interfaces Vistas De instalación
Funciones De configuración
Reglas
Disparadores
30
Otros factores que deben considerarse y que están asociados con la aplicación son los siguientes:
 Complejidad
 Funcionalidad
 Reglas de negocio
 Algoritmos
 Diseño (gráfico)
 Atributos de calidad
o Precisión
o Escalabilidad
o Extensibilidad
o Seguridad
o Usabilidad
o Desempeño
o Otros
 Documentación (del código fuente)
 Estándares de nomenclatura
 Patrones de arquitectura y diseño empleados
 Interfaces con otras aplicaciones
En conclusión, es muy importante conocer cómo está conformado un programa computacional y el software en general,
para poder determinar cómo puede medirse su tamaño.
3.2.3 Utilidad de la medición del tamaño del software
Medir el tamaño del software tiene muchas utilidades tales como:
 Establecer nuevas estimaciones - Comparando la estimación del tamaño de una aplicación con el tamaño de
aplicaciones construidas previamente para determinar la duración, esfuerzo y costo de diseñarla y construirla.
 Medir la densidad de defectos - Estableciendo la cantidad de defectos contenidos por unidad de medida del
tamaño.
 Medir la productividad - Determinando la cantidad de producto (la aplicación) que puede generar un desarrollador
por unidad de tiempo (horas, por ejemplo).
 Determinar el avance de construcción de la aplicación – Identificando el tamaño de producto (aplicación) que ya se
ha construido.
 Seleccionar proveedores – Entregando el tamaño del software a construir, se pueden solicitar cotizaciones a
diferentes proveedores para seleccionar uno.
 Establecer el precio del software – Se puede definir un precio por unidad de medida y con base en el tamaño
determinar el precio total de la aplicación.
31
3.3 Clasificación de las estimaciones
3.3.1 Introducción
Con la finalidad de comprender mejor las estimaciones, se presenta la siguiente clasificación:
Ilustración 7 - Clasificación de las estimaciones
3.3.2 Enfoques de estimación
Ilustración 8 – Clasificación de enfoques de estimación
Las estimaciones pueden clasificarse por su enfoque en:
 De lo general a lo particular (Top-down)

 De lo particular a lo general (Bottom-up)
3.3.1.1 Enfoque de lo general a lo particular (Top-down)

El enfoque de lo general a lo particular, también conocido como el modelo macro, se basa en dividir el alcance del proyecto y
el uso de promedios (ya sea específicos a la organización o a la industria) para estimar el costo y la complejidad asociados
con la implementación de las partes y sus interconexiones.
La característica distintiva del enfoque de lo general a lo particular es que se centra en las propiedades generales del sistema,
tales como la integración, gestión del cambio, y la entrega gradual, combinada con su relativa facilidad de aplicación. Sin
32
embargo, como se mencionó anteriormente, por su naturaleza, este enfoque no es tan bueno como el enfoque de lo particular
a lo general en la captura de los factores de menor nivel, como las cuestiones específicas de cada proyecto, las características
de diseño de aplicaciones, y detalles específicos de la implementación, que tienden a acumularse rápidamente y puede afectar
en gran medida la estimación.
3.3.1.2 Enfoque de lo particular a lo general (Bottom-up)

En los primeros días de la programación informática, la mayoría de las estimaciones de software se producían de forma
ascendente. Se contaban las líneas de código fuente escritas manualmente, que actuaban como una variable clave en las
estimaciones, para calcular el tamaño total del proyecto. La otra variable clave, que era igual de fácil de cuantificar, era la
productividad del desarrollador. La situación empezó a cambiar con la introducción de los diversos lenguajes de programación
(C, Pascal, Ada, Lisp, etc.), los paradigmas de programación (orientado a objetos, basado en plantillas, etc.), las arquitecturas
de hardware, plataformas y la capacidad de generación de código.
El enfoque de lo particular a lo general es generalmente considerado como más intuitivo y menos propenso a errores que el
enfoque de lo general a lo particular. En el caso de componentes bien aislados puede producir estimaciones muy precisas.
Sin embargo, usar solamente el enfoque de lo particular a lo general puede provocar que se pasen por alto limitaciones y
costos significativos a nivel sistema, especialmente cuando se emplea este enfoque en ausencia de suficientes datos de
requerimientos.
3.3.3 Técnicas de estimación
Ilustración 9 - Clasificación de técnicas de estimación
Las técnicas de estimación pueden categorizarse en:
 Basadas en experiencia
 Orientadas al aprendizaje
3.3.3.1 Técnicas de estimación basadas en experiencia

Las técnicas basadas en la experiencia o conocimiento se fundamentan en el juicio subjetivo de un experto, o grupo de
expertos, en la materia.
33
A diferencia de modelos paramétricos más estrictos, estas técnicas se basan principalmente en la experiencia y conocimiento
de los seres humanos, lo cual constituye su principal debilidad. Esta debilidad puede ser mitigada mediante la expansión del
tamaño del grupo de los estimadores.
3.3.3.2 Técnicas de estimación orientadas al aprendizaje

Diversos estudios indican que más de tres cuartas partes de las estimaciones de software se construyen utilizando algún tipo
de analogía o comparación con las soluciones previamente completadas, es decir, utilizan técnicas conocidas como orientadas
al aprendizaje. Aunque intuitivamente similares a las técnicas basadas en la experiencia, las técnicas orientadas al aprendizaje
toman un ángulo diferente. Su objetivo es encontrar un sistema similar producido en otros lugares y, a través de determinar
cómo las propiedades del nuevo sistema pueden variar con respecto al existente, extrapolar la estimación.
La ventaja más evidente de las técnicas de aprendizaje orientado es que la estimación se basa en las características probadas
y no sólo la evidencia empírica, como en el caso de la estimación basada en la experiencia. Una limitación de esta técnica es
la necesidad de determinar las variables más importantes que se utilizan para describir la solución, incluidas las que la
distinguen de la línea de base. Estos objetivos pueden ser difíciles o pueden consumir mucho tiempo para lograrse.
3.3.4 Métodos de estimación
Ilustración 10 - Clasificación de métodos de estimación
Las estimaciones pueden clasificarse por sus métodos en:
 Algorítmicos
o Matemáticos
o Estadísticos
3.3.4.1 Métodos de estimación algorítmicos

Los métodos algorítmicos emplean modelos matemáticos (dirigidos por fórmulas). Toman métricas históricas, calculadas o
estadísticas, tales como líneas de código y el número de funciones, así como factores ambientales conocidos, tales como la
plataforma de programación, el marco de trabajo, la plataforma de hardware y la metodología de diseño, como sus insumos
34
para producir una estimación con un grado o rango conocido de precisión. Por su capacidad de aceptar diferentes métricas
estos métodos son también llamados a veces basados en métricas.
A diferencia de las técnicas no algorítmicas, los métodos algorítmicos pueden producir estimaciones repetibles, y son
relativamente fáciles de ajustar. Estos métodos, sin embargo, son también más sensibles a los datos de entrada inexactos y
pueden llegar a producir estimaciones muy pobres si no se calibran y validan correctamente. Además, estos métodos no
pueden abordar eficazmente circunstancias excepcionales, tales como personal altamente creativo o perezoso, o trabajo en
equipo excepcionalmente fuerte o pobre.
3.4 Técnica de juicio de experto
3.4.1 Introducción
La elaboración de estimaciones mediante el juicio de experto es una de las técnicas más empleadas en nuestra industria,
principalmente cuando se emplean enfoques que van de lo particular a lo general. En este documento se propone el uso del
juicio de experto en combinación con algunas técnicas de descomposición del alcance que permiten identificar los elementos
que van a ser estimados.
3.4.2 Descripción de la técnica
Técnica de estimación
Nombre: Juicio de experto
Propósito: Estimar empleando la experiencia de quien estima.
Enfoque: De lo particular a lo general (Bottom-Up)
Qué estima: Tamaño, duración, esfuerzo, costo, recursos
Procedimiento: 1. Identificar qué se está solicitando o buscando (cumplir un objetivo, establecer un compromiso o
estimar)
2. Identificar, de forma general, cuál es el entregable y/o actividades que se realizarán
(descomponer en caso de ser necesario)
3. Identificar el propósito de la estimación (planear, re-planear, cotizar, otro)
4. Identificar qué se está solicitando estimar (tamaño, duración, esfuerzo, costo o recursos)
5. Solicitar información adicional en caso de ser necesario
6. Resolver dudas en caso de ser necesario
7. Revisar registros de estimaciones previas (para seleccionar alguna en caso de que pueda ser
comparable con la actual)
8. Estimar
9. Registrar y almacenar valores estimados
35
10. Registrar y almacenar suposiciones y razonamientos hechos al estimar

11. Validar estimación
12. Presentar estimación (preferentemente como un rango)
3.5 Técnica Delphi
3.5.1 Introducción
En la técnica Delphi, a un grupo de expertos en la materia se le pide que haga la evaluación de un problema. Durante la ronda
inicial de estimación, cada experto ofrece su evaluación individual y sin consultar a los demás. Después de los resultados de
la ronda inicial se recogen y se clasifican, los participantes se involucran en una segunda ronda de análisis, esta vez con la
información sobre las evaluaciones realizadas por otros participantes. Durante esta ronda se espera reducir la amplitud de los
números, mientras que algunos elementos son considerados para obtener mayor detalle, otros son descartados. Después de
unas cuantas rondas, el equipo llega a una estimación mutuamente acordada.
3.5.2 Descripción de la técnica
Técnica de estimación
Nombre: Delphi
Propósito: Estimar empleando la experiencia varios estimadores.
Procedimiento: 1. Reunir a los estimadores

2. Establecer / comunicar el propósito de la estimación (planear, re-planear, cotizar, otro)
3. Establecer / comunicar el entregable o actividades que se estimarán
4. Establecer / comunicar qué se está solicitando estimar (tamaño, duración, esfuerzo, costo o
recursos)
5. Proporcionar a los estimadores cualquier información que sea relevante
6. Resolver dudas de los estimadores
7. Estimar (cada estimador es responsable de hacerlo)
8. Solicitar a cada estimador su estimación, sin mostrarla a los demás
36
9. Clasificar las estimaciones

10. Entregar la información recolectada y clasificada
11. Detallar información que sea necesaria y descartar la que no
12. Repetir los pasos del 7 al 11 hasta llegar a una estimación mutuamente acordada
3.6 Método de contar, calcular, juzgar
3.6.1 Introducción
Este método consiste en encontrar algún elemento que se pueda contar y que esté altamente relacionado con el tamaño de
la aplicación que se está estimando. Una vez que se hayan contado los elementos de la aplicación multiplíquelos por una
medida de tiempo unitaria. En caso de que no se puedan contar elementos entonces emplee el juicio de experto.
3.6.2 Descripción del método
Método de estimación
Nombre: Contar, calcular, juzgar
Propósito: Estimar descomponiendo el objeto que se va a estimar
Procedimiento: 1. Identificar qué se está solicitando o buscando (cumplir un objetivo, establecer un compromiso o
estimar)
2. Identificar, de forma general, cuál es el entregable y/o actividades que se realizarán
(descomponer en caso de ser necesario)
3. Identificar el propósito de la estimación (planear, re-planear, cotizar, otro)
4. Identificar qué se está solicitando estimar (tamaño, duración, esfuerzo, costo o recursos)
5. Solicitar información adicional en caso de ser necesario
6. Resolver dudas en caso de ser necesario
7. Revisar registros de estimaciones previas (para seleccionar alguna en caso de que pueda ser
comparable con la actual)
8. Identificar y contar los elementos que van a generarse (pantallas, reportes, tablas, etc.)
37
9. Establecer un valor unitario para cada elemento con base en información histórica (duración,
esfuerzo, costo, recursos) (emplear juicio de experto como último recurso)
10. Calcular los valores totales para cada elemento
13. Validar estimación
14. Presentar estimación (preferentemente como un rango)
3.7 Método de análisis de puntos de función
3.7.1 Introducción
Un punto de función es una medida sintética del tamaño de un programa computacional que es a menudo usada en las etapas
tempranas de un proyecto. Los puntos de función son más fáciles de determinar de una especificación de requerimientos que
las líneas de código y proveen una medida más exacta del tamaño de un programa. Existen diferentes métodos para contar
puntos de función.
El análisis de puntos de función es un método estándar para medir el desarrollo de software desde el punto de vista del
usuario. Mide el software cuantificando la funcionalidad que provee al usuario con base en el diseño lógico.
El número de puntos de función en un programa está basado en el número y complejidad de cada uno de los siguientes
elementos:
 Entradas – Pantallas, formas, cajas de dialogo, controles o mensajes a través de los cuales un usuario final u otro
programa agrega, elimina o cambia datos del programa. Esto incluye cualquier entrada que tiene un formato único o
una lógica de procesamiento única.
 Salidas – Pantallas, reportes, gráficas o mensajes que el programa genera para ser usado por un usuario final u otro
programa. Esto incluye cualquier salida que tenga un formato diferente o requiera una lógica de procesamiento
diferente que otros tipos de salidas.
 Consultas – Combinaciones de entrada / salida en las cuales una entrada resulta en una salida simple e inmediata.
El término se originó en el mundo de bases de datos y se refiere a la búsqueda directa de datos específicos,
usualmente empleando una llave única. En las aplicaciones modernas con interfaces gráficas de usuario (GUI –
Graphic User Interface por sus siglas en inglés), la línea entre las consultas y las salidas es borrosa; generalmente,
sin embargo, las consultas regresan datos directamente de una base de datos y proveen formato rudimentario,
mientras que las salidas pueden procesar, combinar o resumir datos complejos y pueden ser altamente formateadas.
38
 Archivos lógicos internos – Grupos lógicos más importantes de datos de usuario final o información de control que
está completamente controlada por el programa. Un archivo lógico puede estar compuesto de un archivo plano o una
tabla de una base de datos relacional.
 Archivos lógicos externos – Archivos controlados por otros programas con los cuales el programa que está siendo
contado interactúa. Esto incluye cada grupo lógico importante de datos o información de control que entra o deja el
programa.
La terminología empleada en el análisis de puntos de función está muy orientada a las bases de datos. El método básico
funciona bien para todos los tipos de software, pero se tendrá que adaptar a cada ambiente si es que no se están construyendo
sistemas con uso intensivo de base de datos.
El procedimiento para contar el tamaño de un programa mediante el análisis de puntos de función se muestra a continuación.
3.7.2 Procedimiento
1. Determinar el tipo de conteo.
2. Identificar el alcance, propósito y límites de la aplicación.
2.1. Identificar el alcance (pantallas, descripciones, necesidades de negocio, casos de uso de negocio, requerimientos
de negocio, etc.).
2.2. Identificar el propósito del conteo (opcional. Ayuda a enfocar y entender el objetivo del conteo)
2.3. Identificar los límites (identificar y diferenciar otras aplicaciones, actores).
3. Contar las funciones de datos.
3.1. Identificar y contar los almacenamientos lógicos (ILF o EIF). ILF si es mantenido por la aplicación, EIF si no es
mantenido por la aplicación. (no incluir tablas temporales, índices o catálogos que solo tienen un identificador y
una descripción).
3.1.1. Determinar la complejidad de cada almacenamiento lógico contando los elementos de datos (DETs y RETs).
3.2. Determinar la contribución de cada almacenamiento lógico, medida en puntos de función con base en la tabla 1 y
tabla 2 (usar ambas tablas solo para nuevos desarrollos).
4. Contar las funciones transaccionales.
4.1. Identificar y contar los procesos elementales clasificándolos en funciones transaccionales (EI, EQ, EO).
4.1.1. Determinar la complejidad de cada función transaccional contando los elementos de datos (DETs FTRs).
4.1.2. Determinar la contribución de cada función transaccional, medida en puntos de función con base en la tabla
3, tabla 4 y tabla 5 (usar las 3 tablas solo para nuevos desarrollos). Ver los criterios de conteo en la
definición de DETs para funciones transaccionales.
5. Determinar los puntos de función no ajustados.

5.1. Sumar los puntos de función de las funciones de datos y funciones transaccionales.
6. Determinar el valor del factor de ajuste. Ver también la tabla 6.
39
7. Determinar los puntos de función ajustados. (Puntos de función ajustados = Puntos de función no ajustados x valor del
factor de ajuste).
El siguiente diagrama presenta algunos de los componentes del método:
Ilustración 11 - Algunos de los componentes del método de análisis de puntos de función
3.7.3 Tablas
3.6.3.1 Tabla 1 - Complejidad de funciones de datos

Tabla para determinar la complejidad de las funciones de datos.
RET\DET 1-19 20-50 50+
1 Baja Baja Media
2-5 Baja Media Alta
6+ Media Alta Alta
3.6.3.2 Tabla 2 – Puntos de función para datos

Puntos de función correspondientes a funciones de datos de acuerdo a su complejidad.
Función de Baja Media Alta

datos
40
ILF 7 10 15
EIF 5 7 10
3.6.3.3 Tabla 3 – Complejidad de entradas externas

Tabla para determinar complejidad de External Input (EI).
FTR\DET 1-4 5-15 16+
0-1 Baja Baja Media
2 Baja Media Alta
3+ Media Alta Alta
3.6.3.4 Tabla 4 – Complejidad de consultas y salidas externas

Tabla para determinar complejidad de External Inquiry (EQ) y External Output (EO).
FTR\DET 1-4 5-15 16+
0-1 Baja Baja Media
2-3 Baja Media Alta
4+ Media Alta Alta
3.6.3.5 Tabla 5 – Puntos de función para transacciones

Puntos de función correspondientes a funciones transaccionales.
Función Baja Media Alta

transaccional
EI 3 4 6
EQ 3 4 6
EO 4 5 7
3.6.3.6 Tabla 6 – Características generales del sistema

Cada característica tiene descripciones asociadas que ayudan a determinar los grados de influencia de dichas características.
Los grados de influencia varían en una escala de cero a cinco, desde "ninguna influencia" hasta "fuerte influencia".
Característica general del sistema Descripción
1 Comunicaciones de datos ¿Qué tanta infraestructura de comunicación existe para ayudar en la

transferencia o intercambio de información con la aplicación o
sistema?
41
2 Procesamiento de datos distribuido ¿Cómo son manejados los datos y funciones de procesamiento
distribuidos?
3 Desempeño ¿Algún valor de tiempo de respuesta o desempeño del procesamiento

fue requerido por el usuario?
4 Configuración intensa de uso ¿Qué tan intensamente es usada la plataforma de hardware actual en
dónde será ejecutada la aplicación?
5 Promedio de transacciones ¿Qué tan frecuentemente son ejecutadas las transacciones?

(diariamente, semanalmente, diariamente, etc.)
6 Entrada de datos en línea ¿Qué porcentaje de la información es introducida en línea?
7 Eficiencia del usuario final La aplicación fue diseñada para tener eficiencia del usuario final?
8 Actualización en línea ¿Qué tantos ILFs son actualizados por transacciones en línea?
9 Procesamiento complejo ¿La aplicación tiene procesamiento lógico y matemático intensivo?
10 Reusabilidad ¿La aplicación fue desarrollada para cumplir una o más necesidades
de usuario?
11 Facilidad de instalación ¿Qué tan difícil es la instalación?
12 Facilidad de operación ¿Qué tan efectivos y/o automatizados son los procedimientos de
arranque, respaldo y recuperación?
13 Sitios múltiples ¿La aplicación fue diseñada, desarrollada y soportada para ser
instalada en múltiples sitios para múltiples organizaciones?
14 Facilidad de cambio ¿La aplicación fue diseñada, desarrollada y soportada para facilitar los
cambios?
42
3.7.4 Diagramas de UML
3.7.4.1 Diagrama 1 – Elementos considerados para el conteo
43
3.7.5 Catálogos
37.5.1 Tipo de conteo
 Nuevo desarrollo y mejoras.

 Mantenimientos.
 Implementación y adquisición de paquetes de software (productos comerciales ya hechos).
3.7.5.2 Propósitos del conteo
 Estimar (esfuerzo, duración, tamaño, costo, etc.).

 Controlar el crecimiento del tamaño durante el desarrollo del producto.
 Controlar la cantidad de producto que es fabricado a lo largo del proyecto.
 Evaluar productividad.
3.7.5.3 Almacenamientos lógicos (funciones de datos)
 ILF – Internal Logical File.

 EIF – External Interface File.
3.7.5.4 Elementos de datos
 DET – Data Element Type

 RET – Record Element Type
3.7.5.5 Funciones transaccionales
 EI (External Input)
 EQ (External Inquiry)
 EO (External Output)
44
3.7.6 Términos asociados con el método
3.7.6.1 Almacenamientos lógicos (funciones de datos)

Se clasifican en ILF (Internal Logical File) y EIF (External Interface File).
También conocidos como entidades de información, deben identificarse en cuanto a que sean totalmente independientes y
que tengan un significado para el usuario. Por ejemplo, índices, tablas temporales son considerados almacenamientos
técnicos creados con propósitos de implementación y no contribuyen al tamaño funcional de la aplicación. Así mismo,
catálogos que contienen sólo un ID y una descripción, son almacenamientos considerados como “Code Table” y tampoco
tendrán una contribución en el tamaño funcional. El punto clave para agrupar los almacenamientos lógicos, es verificando la
dependencia entre ellos. Una pregunta clave, es respondernos si dicho almacenamiento puede existir de manera aislada, o si
para tener significado debe formar parte de otro almacenamiento. Por ejemplo: Si se define la tabla de empleado, y la tabla
telefonos_empleado, ambas son consideradas como un solo almacenamiento lógico, ya que telefonos_empleado no tiene
significado por sí sola.
Otra forma de ver esta independencia, por ejemplo, es reflexionando lo siguiente, si desaparece un registro de la tabla de
empleado ¿tiene sentido para el negocio conservar el registro asociado en telefonos_empleado?. Si la respuesta es positiva,
entonces se considera que cada entidad puede existir de manera independiente y por lo tanto serán dos almacenamientos
lógicos. Por el contrario, si la respuesta es negativa, los almacenamientos no existen de manera independiente, y por lo tanto
son un solo almacenamiento lógico.
3.7.6.2 ILF – Internal Logical File.

Es un tipo de almacenamiento lógico. Será ILF si dicho almacenamiento es mantenido por al menos una función transaccional
dentro de la aplicación se está contando.
3.7.6.3 EIF – External Interface File.

Es un tipo de almacenamiento lógico. Será un EIF si dicho almacenamiento es UNICAMENTE referenciado y no mantenido
por la aplicación que se está contando.
3.7.6.4 DETs (Data Element Types) (para funciones de datos)

Esta definición aplica para las funciones de datos.
Son los campos de datos únicos e identificables por el usuario. Ayudan a identificar la complejidad de un almacenamiento
lógico.
3.7.6.5 DETs (Data Element Types) (para funciones transaccionales)

Esta definición aplica para las funciones transaccionales.
Son los campos únicos de información que son identificables por el usuario y que entran o salen de la función transaccional.
Ayudan a identificar la complejidad de una función transaccional. A continuación se presentan algunos criterios para contar
los DETs en funciones transaccionales:
45
 Para ser contado, el DET debe entrar o salir de la aplicación, es decir, un campo que sea utilizado internamente y
que no entre o salga de la aplicación no es contado como DET.
 Las etiquetas, nombres de campo, nombres de columna y variables de sistema como (fecha de sistema, número de
página, número de columna, etc.) no son contados.
 En aplicaciones on-line, se cuenta 1 DET para la capacidad de ejecución sin importar de cuantas formas distintas se
pueda ejecutar el proceso elemental. Por ejemplo, si se puede ejecutar la función de “Insertar empleado” presionando
el botón “Guardar” o presionando Ctrl-G o dando clic en una opción de menú, sólo se cuenta un DET por la capacidad
para ejecutar dicha función.
 En aplicaciones on-line, se cuenta 1 DET para la capacidad de envío de mensajes, sin importar cuantos mensajes
sean enviados dentro de la misma función transaccional. Por ejemplo, en la función “Insertar empleado”, por ejemplo,
podrían hacerse diversas validaciones sobre cada uno de los datos capturados (longitud del campo, formato de la
fecha, etc.), sin importar cuantas validaciones sean realizadas, sólo se contará un DET por la capacidad de generar
mensajes en dicha función transaccional.
 Contar los drop-downs (combo boxes) como procesos elementales. Contar 1 DET por la capacidad de ejecución
(cuando se presiona la flechita y se despliega el combo box) y un DET por dato mostrado en el combo (se cuentan
los campos, no los registros. Normalmente será un DET – campo por combo box).
3.7.6.6 RETs (Record Element Types)

Son los subgrupos de datos en el mismo almacenamiento y que son identificables por el usuario, cuando en el almacenamiento
no hay subgrupos de datos, se considera que el almacenamiento tiene un solo RET. Ayudan a identificar la complejidad de un
almacenamiento lógico.
3.7.6.7 FTRs (File Type Referenced)

Son las funciones de datos que son mantenidas y/o referenciadas por una función transaccional.
3.7.6.8 Proceso elemental

Es la unidad mínima de actividad significativa al usuario, que deja al negocio en un estado consistente y es autocontenido.
3.7.6.9 Función transaccional

Es un tipo particular de proceso elemental que se define con base en las responsabilidades que le son asignadas. La
complejidad de las funciones transaccionales depende del número de DETs y FTRs.
3.7.6.10 EI (External Input)

Es un tipo de función transaccional. Si el propósito principal de la función es recibir información para administrar (crear,
modificar, eliminar) un almacenamiento, el tipo de función será EI.
46
3.7.6.11 EQ (External Inquiry)

Es un tipo de función transaccional. Si el propósito principal fuera sólo presentar información y no realizar algún
procesamiento adicional, la función es clasificada como EQ.
3.7.6.12 EO (External Output)

Es un tipo de función transaccional. Si el propósito principal es presentar información y además realizar algún
procesamiento adicional (como cálculos matemáticos, derivación de datos, etc.) entonces la función se clasifica como un
EO.
3.7.6.13 Factor de ajuste

El factor de ajuste (VAF - value adjustment factor) puede aumentar o disminuir el valor de los puntos de función en un +/- 35%.
Las características evaluadas para determinar el valor de ajuste se refieren a requerimientos o restricciones no funcionales,
como: comunicaciones de datos, actualización online, complejidad de procesamiento, facilidad de instalación, etc.
Si la calificación de estos factores ambientales es el mínimo, el valor de ajuste será 0.65. Por el contrario, si los factores
ambientales son los más complicados, el valor de ajuste será 1.35.
El valor del factor de ajuste está basado en 14 características generales del sistema (GSCs - General System Characteristics)
que califican la funcionalidad general de la aplicación que se está contando. Cada característica tiene descripciones asociadas
que ayudan a determinar los grados de influencia de dichas características. Los grados de influencia varían en una escala de
cero a 5, desde "ninguna influencia" hasta "fuerte influencia".
3.8 Uso de información histórica para mejorar las estimaciones
3.8.1 Introducción
Un elemento clave para mejorar las estimaciones siempre será la información histórica real que represente el desempeño de
un proyecto. Para poder emplear información histórica y mejorar las estimaciones se vuelve imperante recolectar la
información necesaria durante un proyecto. Dicha información no solamente servirá como entrada al proceso de estimaciones,
sino que muy seguramente representará información útil para medir el desempeño de un proyecto durante sus procesos de
monitoreo y control.
Aunque un objetivo inicial pudiera ser mejorar las estimaciones a nivel individual, en algún momento será necesario contar
con información a nivel proyecto, e inclusive a nivel de cartera de proyectos con el objetivo de monitorear y controlar los costos
(duración y esfuerzo) de dichos proyectos. Es aquí cuando la estandarización, de procesos y herramientas, se vuelve relevante
y otro elemento clave en la ecuación.
Esta sección presenta un modelo ya probado que permite la recolección y almacenamiento de información en proyectos para
que pueda ser empleada como entrada para nuevas estimaciones.
47
3.8.2 Un modelo para obtener información histórica en proyectos de software
3.8.2.1 Introducción
Como ya se mencionó anteriormente, el uso de información histórica es clave para mejorar las estimaciones de proyectos de
software. En esta sección se presenta un modelo probado que permite la recolección y uso de información de tamaño,
duración, esfuerzo y costo de aplicaciones y proyectos para que, además de ser usada como información histórica, permita
incrementar el conocimiento de la organización, principalmente en el desempeño de sus proyectos.
3.8.2.2 Modelo
A continuación se presenta el modelo propuesto para recolectar, almacenar y emplear información histórica de proyectos:
Ilustración 12 - Modelo de recolección, almacenamiento y uso de información histórica para estimaciones
A continuación se describen algunos de los elementos clave del modelo:
 Estimación
o Representa la información de tamaño, duración, esfuerzo y costo aproximados de un nuevo proyecto o
aplicación.
o Emplea, para fines comparativos o de generación de nueva información, la información histórica
almacenada en el repositorio organizacional de métricas.
 Proyecto
48
o Durante éste se recolecta la información necesaria real acerca de su duración, esfuerzo y costo, así como
del tamaño de la aplicación.
o Durante el proyecto también se genera la planeación, que permite tener mayor detalle acerca de la duración,
esfuerzo y costo, comparado con lo originalmente estimado.
 Registro de métricas del proyecto
o Este registro contiene la información consolidada, y probablemente detallada, de la duración, esfuerzo y
costo del proyecto, así como del tamaño de la aplicación.
 Repositorio organizacional de métricas
o Contiene la información consolidada de duración, esfuerzo y costo de todos los proyectos de la organización,
así como el tamaño de todas las aplicaciones generadas o modificadas.
 Herramienta de registro de horas (timesheet)
o Permite el registro de las horas dedicadas a alguna actividad, que a su vez, una vez que se sumen,
representarán las horas dedicadas a un entregable y, estas a su vez, representarán las horas dedicadas a
una fase; así entonces, la suma de las horas dedicadas a una fase representarán las horas dedicadas al
proyecto. Para comprender mejor lo anteriormente mencionado, vea la siguiente figura.
 Cronograma (y su estructura jerárquica)
o Además de que contiene la programación de actividades del proyecto, al final del mismo contendrá la
información real de avance, duración y probablemente esfuerzo y costo de todo el proyecto (siempre y
cuando se haya mantenido actualizado).
o Para poder asegurar el uso de la información de duración, esfuerzo y costo en futuras estimaciones, se
sugiere que se estandarice la estructura jerárquica (WBS – Work Breakdown Structure) de los cronogramas,
tal y como se muestra en la siguiente ilustración.
 Aplicación
o La aplicación construida o modificada aportará el tamaño real de la misma al finalizar el proyecto. Para
poder conocer el tamaño de la aplicación habrá que emplear algún método como por ejemplo el análisis de
puntos de función.
 Sistema de costos estándar
o El sistema de costos estándar, contablemente hablando, es el sistema empleado por la organización para
determinar los costos originados por la producción (desarrollo) del software o de cualquier otro producto o
servicio que ofrezca la empresa.
El siguiente diagrama representa la estructura jerárquica propuesta para estandarizar los cronogramas, así como la
herramienta de registro de actividades (timesheet). Es importante que ambas herramientas (cronograma y timesheet) estén
construidos bajo la misma estructura para asegurar la integridad y homogeneidad de la información a lo largo del ciclo de vida
de los proyectos y la organización en sí.
49
Ilustración 13 - Estructura jerárquica propuesta para estandarización de cronogramas y timesheet
3.8.2.3 Proceso de implementación del modelo

A continuación se presenta un proceso que permite implementar un modelo que facilita la recolección, almacenamiento y uso
de información del desempeño de proyectos y aplicaciones.
Insumos (entradas) Actividades Productos
- Procesos de desarrollo de 1. Estandarizar 3 los procesos relacionados con el desarrollo de software Información de
software de la empresa 2. Estandarizar la herramienta para recolección de horas en proyectos tamaño,
- Estructura jerárquica de (timesheet) duración,
cronogramas 3. Estandarizar la estructura jerárquica de los cronogramas esfuerzo y costo

4. Elaborar cronogramas con base en la estructura jerárquica del proyecto
estandarizada
5. Recolectar información de horas en la herramienta estandarizada de
recolección de horas (timesheet)
3Para efectos de este proceso, estandarizar significa definir e implementar, a nivel organización, y luego usar, a nivel proyecto, el elemento
mencionado.
50
6. Registrar, durante o al finalizar cada proyecto, la información

consolidada real de tamaño (de la aplicación), duración (del proyecto),
esfuerzo y costo.
7. Almacenar la información consolidada real de tamaño, duración,
esfuerzo y costo.
8. Analizar y emplear la información consolidada real de proyectos.
Herramientas
- Herramienta de registro de horas (timesheet)
Roles
Responsables de procesos
Administradores de proyectos
Miembros de equipos de proyectos
Gerente de desarrollo u oficina de proyectos
51
4. Glosario
Actividad
(1) Serie de pasos llevados a cabo para ejecutar un proceso. (ABPMP, 2009)
(2) Un componente de trabajo llevado a cabo durante el curso de un proyecto. (PMI, 2008)
(3) Trabajo que una compañía u organización lleva a cabo usando procesos de negocio. Una actividad puede ser atómica o
no atómica (compuesta). Los tipos de actividades que son parte de un modelo de procesos son: procesos, subprocesos y
tareas. (OMG, 2011)
(4) Unidad tangible de trabajo realizada por un trabajador en un flujo de trabajo, de forma que implica una responsabilidad
bien definida para el trabajador, produce un resultado bien definido (un conjunto de artefactos) basado en una entrada bien
definida (otro conjunto de artefactos), y representa una unidad de trabajo con límites bien definidos a la que, probablemente
se refiera el plan de proyecto al asignar tareas a los individuos. También puede verse como la ejecución de una operación por
un trabajador. (Jacobson, Booch, & Rumbaugh, 2000)
Aplicación
Ver Software de aplicación.
Ciclo de vida (de proyecto)
(1) Una colección de fases de proyecto, generalmente secuenciales, cuyo nombre y número son determinados por las
necesidades de control de la organización u organizaciones involucradas en el proyecto. Un ciclo de vida puede ser
documentado con una metodología. (PMI, 2008)
(2) Una partición de la vida de un producto, servicio, proyecto, grupo de trabajo o conjunto de actividades de trabajo en fases.
(SEI, 2010)
Ciclo de vida (del software)
(1) El periodo que comienza cuando un producto de software es concebido y concluye cuando el software ya no está disponible
para su uso. El ciclo de vida del software típicamente incluye las siguientes fases: concepto, requerimientos, diseño,
implementación, pruebas, instalación, operación y mantenimiento, en algunas ocasiones se incluye una fase de
descontinuación. Estas fases pueden traslaparse o ser ejecutadas iterativamente. (IEEE, 1990)
(2) Ciclo que cubre cuatro fases en el siguiente orden: inicio, elaboración, construcción y transición. (Jacobson, Booch, &
Rumbaugh, 2000)
Cliente
(1) Persona que utiliza con asiduidad los servicios de un profesional o empresa. (RAE, 2012)
(2) La parte responsable de aceptar el producto o autorizar un pago. El cliente es externo al proyecto o grupo de trabajo pero
no necesariamente externo a la organización. El cliente puede ser un proyecto o grupo de trabajo de más alto nivel. Los
clientes son un subconjunto del grupo de interesados en el proyecto. (SEI, 2010)
52
(3) Persona, organización o grupo de personas que encarga la construcción de un sistema, ya sea empezando desde cero, o
mediante el refinamiento de versiones sucesivas. (Jacobson, Booch, & Rumbaugh, 2000)
Componente
Una parte física y reemplazable de un sistema que se ajusta a, y proporciona la realización de, un conjunto de interfaces.
(Jacobson, Booch, & Rumbaugh, 2000)
Costo
El costo es la cantidad que se da o se paga por algo. (RAE, 2012)
Defecto
(1) Imperfección en algo o en alguien. (RAE, 2012)
(2) Carencia de alguna cualidad propia de algo. (RAE, 2012)
(3) Una imperfección o deficiencia en un componente de un proyecto en la cual dicho componente no cumple sus
requerimientos o especificaciones y necesita ser corregido o reemplazado. (PMI, 2008)
(4) Anomalía del sistema, por ejemplo un síntoma de un error en el software descubierto durante las pruebas, o un problema
descubierto durante una reunión de revisión. (Jacobson, Booch, & Rumbaugh, 2000)
Duración
El número total de periodos de trabajo (sin incluir días festivos u otros periodos no laborables) requerido para completar una
actividad programada o un componente de una estructura de desglose de trabajo. Usualmente expresada como días o
semanas laborables. (PMI, 2008)
Entrada
Cualquier elemento, interno o externo al proyecto que es requerido por un proceso antes de que el proceso proceda. Puede
ser una salida de un proceso predecesor. (PMI, 2008)
Ver también: Insumo.
Entregable
Cualquier producto único y verificable, resultado o capacidad para llevar a cabo un servicio que debe ser producido para
completar un proceso, fase o proyecto. A menudo usado más estrechamente en referencia a un entregable externo, que es
un entregable que está sujeto a aprobación del patrocinador o cliente del proyecto. (PMI, 2008)
Un elemento que será provisto a un adquiriente u cualquier otro recipiente designado tal como fue especificado en un acuerdo.
El elemento puede ser un documento, elemento de hardware, elemento de software, servicio o cualquier tipo de producto de
trabajo. (SEI, 2010)
53
Error
(1) Acción desacertada o equivocada. (RAE, 2012)
(2) Una acción humana que produce un resultado incorrecto. (IEEE, 1990)
(3) La diferencia entre un valor o condición computado, observado o medido y la condición o valor verdadero, especificado o
teóricamente correcto. Por ejemplo, una diferencia de 30 metros entre un resultado computado y el resultado correcto. (IEEE,
1990)
(4) Un resultado incorrecto. Por ejemplo, un resultado computado de 12 cuando el resultado correcto es 10. (IEEE, 1990)
Esfuerzo
El número de unidades de trabajo requeridas para completar una actividad programada o un componente de una estructura
de desglose de trabajo. Usualmente expresado como horas/hombre, días/hombre o semanas/hombre. (PMI, 2008)
Fase (de proyecto)
(1) Una colección de actividades de un proyecto relacionadas lógicamente, usualmente culminando en la conclusión de un
entregable importante. Las fases de un proyecto son concluidas principalmente de forma secuencial, pero pueden empalmarse
en algunas situaciones del proyecto. Una fase de proyecto es un componente del ciclo de vida del proyecto. (PMI, 2008)
(2) Periodo de tiempo entre dos hitos principales de un proceso de desarrollo. (Jacobson, Booch, & Rumbaugh, 2000)
Hito
(1) Un punto o evento significativo en el proyecto. (PMI, 2008)
(2) Punto en el que han de tomarse importantes decisiones de negocio. Punto de sincronización en el que coinciden una serie
de objetivos bien definidos, se completan artefactos, se toman decisiones de pasar o no a la fase siguiente, y en el que las
esferas técnica y de gestión entran en conjunción. (Jacobson, Booch, & Rumbaugh, 2000)
Indicador
Un dispositivo o variable que puede ser configurada con un estado prescrito con base en los resultados de un proceso o la
ocurrencia de una condición especificada. Por ejemplo, una bandera o semáforo. (IEEE, 1990)
Instrumento o herramienta
Producto que facilita el trabajo durante la ejecución de un proceso.
Insumo
Producto requerido para ejecutar un proceso.
Ver también: Entrada.
54
Interfaz
(1) Un límite compartido a través del cual la información es pasada. (IEEE, 1990)
(2) Un componente de hardware o software que conecta dos o más componentes con el propósito de pasar información de
uno a otro. (IEEE, 1990)
(3) Conectar dos o más componentes con el propósito de pasar información de uno a otro. (IEEE, 1990)
(4) Servir como un componente conectado o para conectar tal como se especifica en (2). (IEEE, 1990)
Iteración
(1) El proceso de llevar a cabo una secuencia de pasos repetidamente. (IEEE, 1990)
(2) Una sola ejecución de la secuencia de pasos en (1). (IEEE, 1990)
(3) Conjunto de actividades llevadas a cabo de acuerdo a un plan (de iteración) y unos criterios de evaluación, que lleva a
producir una versión, ya sea interna o externa. (Jacobson, Booch, & Rumbaugh, 2000)
Medición
Acción y efecto de medir. (RAE, 2012)
Un conjunto de operaciones para determinar el valor de una medida. (SEI, 2010)
Medida
Expresión del resultado de una medición. (RAE, 2012)
Variable a la cual se le asigna un valor como resultado de una medición. (SEI, 2010)
Métrica
(1) Una medida cuantitativa del grado en el cuál un sistema, componente o proceso posee un determinado atributo. (IEEE,
1990)
(2) Perteneciente o relativo al metro. (RAE, 2012)
Modelo
(1) Arquetipo o punto de referencia para imitarlo o reproducirlo. (RAE, 2012)
(2) Representación en pequeño de alguna cosa. (RAE, 2012)
(3) Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja, como la evolución
económica de un país, que se elabora para facilitar su comprensión y el estudio de su comportamiento. (RAE, 2012)
(3) Una abstracción de un sistema cerrada semánticamente. (Jacobson, Booch, & Rumbaugh, 2000)
55
Patrón
Solución a un problema común de un determinado contexto. (Jacobson, Booch, & Rumbaugh, 2000)
Proceso
(1) Un conjunto definido de actividades o comportamientos llevados a cabo por humanos o máquinas para alcanzar uno o
más objetivos. (ABPMP, 2009)
(2) Una secuencia de pasos llevados a cabo para un propósito dado. (IEEE, 1990)
(3) Una secuencia o flujo de actividades en una organización con el objetivo de llevar a cabo trabajo. (OMG, 2011)
(4) Un conjunto de actividades interrelacionadas, las cuales transforman salidas en entradas, para cumplir un propósito dado.
(SEI, 2010)
(5) Un flujo de control pesado que puede ejecutarse concurrentemente con otros procesos.
Proceso de negocio
(1) Trabajo llevado a cabo de principio a fin que entrega valor a los clientes. (ABPMP, 2009)
(2) Un conjunto definido de actividades de negocio que representa los pasos requeridos para alcanzar un objetivo de negocio.
Incluye el flujo, uso de información y recursos. (OMG, 2011)
(3) Conjunto total de actividades necesarias para producir un resultado de valor percibido y medible para un cliente individual
de un negocio. (Jacobson, Booch, & Rumbaugh, 2000)
Producto
(1) Cosa producida. (RAE, 2012)
(2) Un artefacto que es producido, es cuantificable y puede ser un elemento final o un componente. (PMI, 2008)
Ver también: Salida.
Programa de computadora
Una combinación de instrucciones de computadora y definiciones de datos que permiten al hardware de computadora llevar
a cabo funciones computacionales o de control. (IEEE, 1990)
Proyecto
(1) Es un esfuerzo temporal realizado para crear un producto, servicio o resultado únicos. (PMI, 2008)
(2) Esfuerzo de desarrollo para llevar un sistema a lo largo de un ciclo de vida. (Jacobson, Booch, & Rumbaugh, 2000)
La naturaleza temporal de los proyectos indica un inicio y un fin definidos. El fin es alcanzado cuando los objetivos del proyecto
han sido alcanzados o cuando el proyecto es terminado puesto que sus objetivos no pueden o no podrán ser cumplidos, o
cuando la necesidad de continuar el proyecto ya no exista. (PMI, 2008)
56
Riesgo
Variable de un proyecto que pone en peligro o impide su éxito. (Jacobson, Booch, & Rumbaugh, 2000)
Rol
(1) Una función definida para ser llevada a cabo por el miembro de un equipo de proyecto, tal como prueba, inspección,
codificación. (PMI, 2008)
(2) El comportamiento específico de una entidad que participa en un contexto particular.
Salida
Un producto, resultado o servicio generado por un proceso. Puede ser una entrada para un proceso sucesor. (PMI, 2008)
Ver también: Producto.
Servicio
Un producto que es intangible y no almacenable. (SEI, 2010)
Los servicios son entregados a través del uso de sistemas de servicios que han sido diseñados para satisfacer requerimientos
de servicio. (SEI, 2010)
Muchos proveedores de servicios entregan combinaciones de servicios y bienes. Un sistema de servicios puede entregar
ambos tipos de productos. (SEI, 2010)
Los servicios pueden ser entregados a través de combinaciones de procesos manuales y automatizados. (SEI, 2010)
Sistema
(1) Conjunto de cosas que relacionadas entre sí ordenadamente contribuyen a determinado objeto. (RAE, 2012)
(2) Una colección de subsistemas organizados para llevar a cabo un propósito específico y descritos por un conjunto de
modelos, posiblemente desde distintos puntos de vista.
Sistema computacional
Un sistema que contiene una o más computadoras y software asociado. (IEEE, 1990)
Software
Es el conjunto de programas de computadora, procedimientos, datos y documentación asociada pertenecientes a la operación

de un sistema computacional. (IEEE, 1990)
57
Software de aplicación
(1) Software diseñado para cumplir con necesidades específicas de un usuario, por ejemplo, software de nómina, recursos
humanos o ventas. (IEEE, 1990)
(2) Sistema que ofrece a un usuario final un conjunto coherente de casos de uso. (Jacobson, Booch, & Rumbaugh, 2000)
También conocido como LOB, Line of Business Application.
Subproceso
Un proceso que está incluido dentro de otro proceso. (OMG, 2011)
Tarea
(1) Actividad con inicio y fin definidos.
(2) Una actividad atómica que está incluida dentro de un proceso. Una tarea es usada cuando el trabajo en el proceso no es
descompuesto para obtener un nivel más fino de detalle en el modelado del proceso. Generalmente, un usuario final, una
aplicación o ambos llevarán a cabo la tarea. (OMG, 2011)
Patrocinador
La persona o grupo que provee los recursos financieros, en efectivo o especie, para el proyecto. (PMI, 2008)
Usuario (final)
(1) Una de las partes que emplea un producto entregado o que recibe el beneficio de un servicio entregado. Los usuarios
finales también pueden, o no, ser clientes. (SEI, 2010)
(2) Humano que interactúa con un sistema. (Jacobson, Booch, & Rumbaugh, 2000)
5. Referencias
ABPMP. (2009). Guide to the Business Process Management Common Body of Knowledge (BPM CBOK) Version 2.0.
Chicago: Association of Business Process Management Professionals.
Barker, C. (2007, 11 22). The top 10 IT disasters of all time. Retrieved from ZDNet: http://www.zdnet.com/the-top-10-it-
disasters-of-all-time-3039290976/
Booch, G., Rumbaugh, J., & Jacobson, I. (2006). El lenguaje unificado de modelado. Pearson Education.
Calleam Consulting Ltd. (2012, 11 20). Denver Airport Baggage System Case Study. Retrieved from Why Projects Fail:
http://calleam.com/WTPF/?page_id=2086
Domínguez, J. (2012, 11 16). The Curious Case of the CHAOS Report 2009. Retrieved from ProjectSmart.co.uk:
http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html
Gary, K. P. (2003). Fundamentos de Marketing, Sexta Edición. Prentice Hall.
58
IBM. (2013, 04 16). RUP: Best practices for design, implementation and effective project management. Retrieved from IBM
Web Site: http://www-01.ibm.com/software/rational/rup/
IEEE. (1990). IEEE Standard Glossary of Software Engineering Terminology. New York: The Institute of Electrical and
Electronics Ehgineers.
IFPUG. (2012, 11 22). About Function Point Analysis. Retrieved from International Function Point Users Group:
http://www.ifpug.org/?page_id=10
IVEX. (2007). El mercado del software en México. Ciudad de México: Instituto Valenciano de la exportación.
Jacobson, I., Booch, G., & Rumbaugh, J. (2000). El proceso unificado de desarrollo de software. Madrid, España: Addison
Wesley.
Karl T. Ulrich, S. D. (2009). Diseño y desarrollo de productos, cuarta edición. Mc Graw Hill.
KUALI-KAANS. (2013, 04 04). KUALI-BEH. Retrieved from KUALI-KAANS: http://www.kuali-kaans.mx/proyectos/kuali-beh
Lamb Charles, H. J. (2002). Marketing, Sexta Edición. International Thomson Editores S.A.
McConnell, S. (1996). Chapter 2: Rapid-Development Strategy. In S. McConnell, Rapid Development (Taming Wild Software
Schedules) (p. 22). Redmond, Washington: Microsoft Press.
McConnell, S. (1996). Rapid Development (Taming Wild Software Schedules). Redmond, Washington: Microsoft Press.
McConnell, S. (1998). Software Project Survival Guide. Redmond, Washington: Microsoft Press.
McConnell, S. (2006). Software Estimation (Demystifying the Black Art). Redmond, Washington: Microsoft Press.
Oktaba, H. (2010, 03 07). Historia estándar ISO/IEC 29110. Retrieved from ISO/IEC 29110: http://iso29110.kuali-
kaans.mx/iso29110/index.php?option=com_content&view=section&layout=blog&id=3&Itemid=8&lang=es
OMG. (2011). A Foundation for the Agile Creation and Enactment of Software Engineering Methods. Needham, MA: OMG.
OMG. (2011). Business Process Model and Notation (BPMN). Needham, MA: Object Management Group.
Pareja Quinaluisa, J. F. (2012, 02 08). Evaluación de procesos de software utilizando EvalProSoft aplicado a un caso de
estudio. Retrieved from Escuela Politécnica Nacional: http://bibdigital.epn.edu.ec/handle/15000/4491
PMI. (2008). A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition. Pennsylvania: Project
Management Institute, Inc.
RAE. (2012, 11 08). Diccionario de la lengua española. Retrieved from Real Academia Española: http://www.rae.es
Richard, S. L. (2002). Mercadotecnia, Primera Edición. Compañía Editorial Continental.
Rubinstein, D. (2007, 3 1). Standish Group Report: There's Less Development Chaos Today. Retrieved from SD Times:
http://www.sdtimes.com/content/article.aspx?ArticleID=30247
Secretaría de economía. (2012, 11 13). Capital humano - estimación del capital humano de las personas. Retrieved from
Sistema nacional de indicadores de la industria de tecnologías de información:
http://www.edigital.economia.gob.mx/capital%20humano.htm
Secretaría de economía. (2012). Ejercicio de Rendición de Cuentas a la Sociedad PROSOFT 2012. Ciudad de México:
Secretaría de economía.
Secretaría de economía. (2012, 11 13). Mercado nacional. Retrieved from Sistema nacional de indicadores de la industria de
tecnologías de información: http://www.edigital.economia.gob.mx/MNACIONAL.htm
59
SEI - Software Engineering Institute. (2013, 04 16). Team Software Process - A Performance Framework for Software
Development. Retrieved from SEI Web Site: http://www.sei.cmu.edu/library/upload/TSPoverview.pdf
SEI - Software Engineering Institute. (2013, 04 16). The Personal Software Process (PSP). Retrieved from SEI Web Site:
http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm
SEI. (2010). CMMI for Acquisition, Version 1.3 (CMU/SEI-2010-TR-032). Hanscom AFB, MA: Software Engineering Institute.
SEI. (2010). CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033). Hanscom AFB, MA: Software Engineering
Institute.
SEI. (2010). CMMI for Services, Version 1.3 (CMU/SEI-2010-TR-034). Hanscom AFB, MA: Software Engineering Institute.
Stanton William, E. M. (2004). Fundamentos de Marketing, 13va. Edición. Mc Graw Hill.
The Standish Group. (1995). Chaos Report. The Standish Group.
Villalobos Hernández, M., & Gutiérrez Tornés, A. (2001). Investigación sobre las prácticas de ingeniería de software. Ciudad
de México: CIC-IPN.
Wikipedia. (2012, 10 24). Lean IT. Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Lean_IT
60

Estimaciones de Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Estimaciones de Software

Cargado por

Copyright:

Formatos disponibles

ESTIMACIONES DE

Rogelio Francisco Ramírez Ramírez

2.1 Conceptos clave .............................................................................................................................................................. 3

2.2 Porque las palabras importan .......................................................................................................................................... 3

2.3 La crisis del software........................................................................................................................................................ 6

2.4 El software como negocio ................................................................................................................................................ 9

2.5 Bibliografía recomendada .............................................................................................................................................. 15

3.1 Introducción ................................................................................................................................................................... 16

3.2 El tamaño del software................................................................................................................................................... 29

3.3 Clasificación de las estimaciones .................................................................................................................................. 32

3.4 Técnica de juicio de experto .......................................................................................................................................... 35

3.5 Técnica Delphi ............................................................................................................................................................... 36

3.6 Método de contar, calcular, juzgar ................................................................................................................................. 37

3.7 Método de análisis de puntos de función ....................................................................................................................... 38

3.8 Uso de información histórica para mejorar las estimaciones ......................................................................................... 47

2.1 Conceptos clave

Es el conjunto de programas de computadora, procedimientos, datos y documentación asociada pertenecientes a la operación

2.1.2 Programa de computadora

Para mayor información acerca de estos conceptos ver el Glosario.

2.2 Porque las palabras importan

2.2.1 Diferencia entre sistema, software, aplicación y programa

2.2.2 Diferencia entre programa computacional y proyecto

2.2.3 Diferencia entre error, defecto y falla

2.2.4 Diferencia entre costo y precio

2.2.5 Diferencia entre duración y esfuerzo

2.3 La crisis del software

2.3.1 Hacer software no es lo mismo que programar

2.3.2 Reporte del caos

Proyectos 1994 1996 1998 2000 2002 2004 2006 2009

Exitosos 16% 27% 26% 28% 34% 29% 35% 32%

Desafiados 53% 33% 46% 49% 51% 53% 46% 44%

Fallidos 31% 40% 28% 23% 15% 18% 19% 24%

Fuente: (Domínguez, 2012)

Fallidos: fueron cancelados y no terminaron.

 Mejor administración de proyectos

2.3.3 Casos de estudio

2.3.3.1 Software de manejo de equipaje del aeropuerto de Denver

(Calleam Consulting Ltd, 2012)

2.3.3.2 El colapso de la red de AT&T

2.3.3.3 La explosión de Ariane 5

2.4 El software como negocio

2.4.1 Programar vs hacer dinero

Intereses de un programador de software:

 Adquisición de nuevo conocimiento técnico.

2.4.2 Desperdicio relacionado al software

Tabla 2 Objetivos de desperdicio en Lean IT

Desperdicio Ejemplo En qué se traduce en el negocio

Cálculo mal realizado por un programa computacional Costos adicionales de corrección

No aprovechamiento de los recursos en

No aprovechamiento de los recursos en

Posible incremento de costos (por

Movimiento Asistencia a reuniones para llegar a acuerdos. Pérdida de productividad

Desplazamientos necesarios (para ir al baño, para

Conocimiento no No existencia de una base de conocimiento Baja satisfacción con el trabajo

Comisión de los mismos errores de forma recurrente mantenimiento y soporte

Fuente: (Wikipedia, 2012)

2.4.3 Costo y precio

2.4.4 Reducción de costos mediante la prevención

Ilustración 1 Costo de corrección de un defecto de acuerdo a la fase en que es corregido

2.4.5 Costeo del software

2.5 Bibliografía recomendada

3.1.1 ¿Qué es una estimación?

Existen diferentes definiciones de estimación, a continuación se presentan algunas: