1.

Planeación, cálculo y estimación de tamaño

2.1 Planeación de Proyectos

¿Qué es un proyecto de sistema o software?

Para poder desarrollar un proyecto o sistema es necesario realizar diversas

actividades en las cuales se encuentra la estimación la cual es ver hacia el futuro,
como costo, tiempo, y la planificación, tomando en cuenta los procedimientos,
recursos el alcance o tamaño del proyecto.

Pero algo muy importante es la información a la cual ese estará consultando, ya

que de ello puede determinarse un riesgo de estimación.

Objetivo de la planificación del proyecto

El objetivo de la planificación de un proyecto es proporcionar un gestor de

estimaciones para los recursos, costos y planificación temporal.

Las estimaciones se realizan dentro de un tiempo determinado, antes de

comenzar el proyecto y una vez realizado se deben de realizar actualizaciones a
medida que va avanzando el proyecto, para identificar los escenarios para
prevenir afectaciones al proyecto y poderlos limitar.

2.2 Medición de tamaño

Medición, Frenton y Pfleeger (1996), lo definen como “El proceso por el cual se
asignan números o símbolos a los atributos de las entidades del mundo real, para
describirlos de acuerdo a reglas claramente definidas.”

Es necesario conocer el tamaño del software para así tener estimaciones de

costos, cronograma, personal y esfuerzo del proyecto. El tamaño del software
puede ser medido, pero ¿qué es lo que se mide?, esto depende del software,
existen medidas técnicas y funcionales, las medidas técnicas son las utilizadas
para cuantificar procesos y productos de acuerdo al punto de vista del
desarrollador, las medidas funcionales son utilizadas para cuantificar los productos
y servicios del software bajo una perspectiva del usuario.
 2.2.1 Conteo de programas

Las medidas en PSP son el tamaño del programa, el tiempo gastado en cada fase
y los defectos encontrados e inyectados por fase, estas son las más básicas,
algunas otras son:
Los datos reales y estimados para cada ítem, y las medidas derivadas, como la
planeación de soporte y la caracterización del proceso de calidad.

Para contar el tamaño del programa se revisa:

 Líneas lógicas
o Invariables a los cambios de edición
o Se relacionan con el esfuerzo de desarrollo
o Definidas de manera única
o Complejas de contar
 Líneas físicas
o Fáciles de contar
o No son invariables a la edición
o Deben ser definidas para cada caso

PSP utiliza un estándar de codificación y un contador de líneas físicas para medir

LOC
o Estándar de codificación
o Línea física para cada línea lógica
El estándar debe ser seguido detenidamente, y el conteo de LC físicas es igual al
conteo de líneas lógicas.

2.2.2 Estándar de conteo

Para ello se cuentan todas las sentencias:

@ anotaciones
{,},;
Declaraciones, imports, etc.

No se deben contar las líneas en blanco, los comentarios o el código generado

automáticamente
Solo se cuenta el código adicionado o modificado para medir y estimar la
productividad del desarrollo.
Ejemplo:

//El programa lee tres números y escribe el mayor de los tres.

#include <stdio.h>

int main(){

double a,b,c;

//Lectura de datos

printf("Escribe el primer número");

scanf("%lf",&a);
printf("Escribe el segundo número");
scanf("%lf",&b);
printf("Escribe el tercer número");
scanf("%lf",&c);

if(a>b && a>c) { //El mayor es a

if(b>a) printf("\t%lf\t%lf\t%lf", a, b, c);

else printf("\t%lf\t%lf\t%lf", a, c, b);

}
else if (b>a && b>c) { //El mayor es b

if (a>c) printf("\t%lf\t%lf\t%lf", b, a, c);

else printf("\t%lf\t%lf\t%lf", b, c, a);

}
else { //El mayor es c

if (a>b) printf("\t%lf\t%lf\t%lf", c, a, b);

else printf("\t%lf\t%lf\t%lf", c, b, a);

}
Nombre/Definición:
_________________________________________________Lenguajes: ____________

Autor: ______________________________________ Fecha________________

Tipo de Conteo Tipo Comentarios

Físico / Lógico

Tipo de Instrucción Incluido Comentarios

Ejecutable

No ejecutable

Declaraciones

Directivas del compilador

Comentarios

En líneas propias

Con el fuente

Líneas en blanco

Aclaraciones Ejemplos / Casos

Nulos

Instrucciones vacías

Instanciadores genéricos

Begin…end

Begin…end

Prueba de condiciones

Evaluación de expresiones

Símbolos End

Símbolos End
Then, else, otherwise

Else if

Palabras clave

Etiquetas

Nota 1

Nota 2

Nota 3

Nota 4
Formato lleno

Nombre/Definición: Sánchez_Pimentel _Oscar_____________________

Lenguajes: __C_______

Autor: ___Castro Medina Luis_________________________ Fecha: 04 / 02 / 15___

Tipo de Conteo Tipo Comentarios

Físico / Lógico

Tipo de Instrucción Incluido Comentarios

Ejecutable Si

No ejecutable Si

Si, nota
Declaraciones 1

Directivas del
compilador Si

Comentarios No

En líneas propias No

Con el fuente No

Encabezados No

Líneas en blanco No

Aclaraciones Ejemplos / Casos

Nulos No continues, no-ops

Instrucciones vacías Si ";;", ;´s solos, etc.

Instanciadores
genéricos

Si, nota
Begin…end 3 Cuando estén en código ejecutable

Begin…end Cuando estén en código no ejecutable

Si, nota
 3

Prueba de condiciones Si

Evaluación de
expresiones Si Cuando se use como argumentos de subprogramas

Símbolos End No Cuando terminen instrucciones ejecutables

Símbolos End No Cuando terminen declaraciones o cuerpos

Si, nota
Then, else, otherwise 4

Si, nota
Else if 4

División de procedimientos, interfaz,

Palabras clave No implementación

Destinos de saltos cuando estén en líneas

Etiquetas No separadas

Se contara una, o un; por casa declaración de

Nota 1 variable o parámetro

Contar cada #include, # define por cada # que

Nota 2 aparezcan en el código

Se contara un Begin…End por cada { que aparezca

Nota 3 en el código

Se contara 1 línea por cada una de las siguientes

palabras reservadas, if, else, do, while, for, switch,
Nota 4 case, etc.
 2.3. Estándar de codificación

Esta forma se introduce a partir del PSP 0.1. la función de esta forma es planear
como se va a realizar cada uno de los módulos de las tareas a realizar.

Se debe definir el encabezado, la declaración de las variables, la función de los

módulos, el resumen del listado de los módulos, la descripción de las
constantes y librerías.

Propósito Guiar el desarrollo de programas

Encabezados del
programa

Formato del encabezado

Contenido del listado

Ejemplo del contenido

Instrucciones de
Reutilización

Ejemplo

Identificadores

Ejemplo de
Identificadores

Comentarios

Buen Comentario

Mal comentario

Secciones Importantes

Ejemplo

Espacios en blanco

Sangrías

Ejemplo
 Mayúsculas

Ejemplo de Mayúsculas

Formato con datos

Propósito Guiar el desarrollo de programas

Encabezados del Todos los programas comienzan con un encabezado

programa descriptivo

/********************************************
Nombre del programa: lexico.c
Autor: Sánchez Pimentel Oscar
Materia: Proyecto de Investigación 1
Formato del
Tarea: PSP2A
encabezado
Fecha: 04/02/15
Descripción: Este programa cuenta líneas de
código
*******************************************/

Contenido del listado Proporciona un resumen del contenido del listado

Ejemplo del contenido /*******************************************

El archivo contiene los siguientes elementos
Funcion_1{}
Funcion_2{}
.
.
.
Funcion_n{}
********************************************/
Nota: en caso de que sea una sola función no se
declara el contenido.
 Describe como se usa el programa. Proporciona un
formato de declaración, tipos y valores de parámetros y
límites de parámetros.
Instrucciones de
Proporciona advertencias de valores ilegibles,
Reutilización
condiciones de sobreflujo u otras condiciones que
podrían resultar potencialmente en una operación
inadecuada.

/********************************************
void lee_archivo (char nomarch{})
Ejemplo
Propósito: esta función regresa el nombre de
un archivo
********************************************/

Utilice nombres descriptivos para todas las variables,

nombres de funciones, constantes y otros
Identificadores
identificadores. Evite abreviaturas o nombres de
variables con un solo carácter.

Ejemplo de int tamanio_buffer ; //Correcto

Identificadores int x; //Incorrecto

Comentarios Documente lo suficiente el código para que el lector

pueda comprender su operación. Los comentarios
deben explicar tanto el proposito como el
comportamiento del código. Comente la declaración de
las variables para indicar su proposito

Buen Comentario /* Se lee una linea de código */

if (carácter =='{')
...

Mal comentario //cuenta un

//un operador {
if (carácter=='{')

Secciones Importantes Las secciones importantes del programa deben estar

precedidas por un bloque de comentarios que
describan el procesamiento que se hace en la siguiente
sección
 /***
Esta función recibe una lista ligada y
Ejemplo calcula la media de una serie de numeros
***/
int media(nodo * lista)

Espacios en blanco Escriba programas con el suficiente espaciamiento tal

que sean fáciles de leer. Separe cada construcción del
programa con al menos un espacio

Coloque sangrías en cada nivel de bloque con respecto

Sangrías al anterior. Laves que abren y cierran deben estar en
una sola línea y alineadas una con la otra

for (cont=0; cont < TAMMAX; cont++)

{
suma + =cont;
if (suma < CERO)
contenido del listado
{
suma =- suma;
}
}

Todos los define van en mayúsculas.

Todos los otros identificadores y palabras reservadas
van en minúsculas. Los
Mayúsculas
mensajes que son salidas al usuario pueden tener
mezcla de mayúsculas y minúsculas de tal manera que
hagan más limpia la presentación al usuario.

#define TAMBUFFER
Ejemplo de Mayúsculas
while (cont != TAMBUFFER)
 2.4. Antecedentes de estimación

Se dice que realizar una estimación es difícil, por ello es que se argumenta que la
estimación es un PROCESO DE REFINAMIENTO GRADUAL.

El desarrollo de un software se comienza con una imagen borrosa de lo que se

desea construir y en el transcurso del desarrolla la imagen se va tornando más
clara. La estimación de tiempo y del esfuerzo necesario para el desarrollo del
software es también poco clara.

Para conocer la estimación de un proyecto es necesario conocer y comprender el

alcance y las funciones del sistema.

Los factores que influyen en el costo del software.

Para conocer la estimación del proyecto a desarrollar se debe de realizar una

planeación del proyecto antes de dar a conocer el costo final del proyecto, durante
el estudio preliminar del problema y durante el análisis de la factibilidad se realiza
un estimación inicial, durante las especificaciones del software se realiza una
estimación mejorada y finalmente en la revisión del diseño se realiza la estimación
final.

Los principales factores que afectan el costo que tendrá el software son

1. Capacidad del programador

2. Complejidad del producto
3. Tamaño del programa
4. Tiempo disponible
5. Confiabilidad requerida

Capacidad del programador

La producción de productos de programación son actividades que requieren de un

tiempo adecuado para su elaboración, debido a que cada producto de
programación es resultado de una función directa de la capacidad individual.

Es importante que cada persona que realice estas actividades de sistema, sea
experto en la programación ya que de lo contrario esto atrasaría la productividad,
y por ello aumentaría el costo y el esfuerzo.

Complejidad del producto

 Procesamiento de Datos

Programas de
Programas Científicos
Aplicación

Categorías de
Programas de Compiladores
productos de
Apoyo
programación

Programas de Ligadores
Sistemas

Sistemas de Bases de Datos

Sistemas Operativos
Sistemas de Tiempo Real -
Complejidad

Tamaño del producto

Costo del Producto

Tamaño del producto

Tiempo disponible

El esfuerzo destinado para el desarrollo del proyecto se considera de acuerdo a

los proyectos de programación debido a que si el tiempo se reduce se requiere
más esfuerzo para la programación.

Nivel de confiabilidad requerido

La confiablidad de un proyecto se expresa en términos de exactitud, firmeza,

cobertura y de la consistencia del código fuente, para ello se debe estimar el costo
en los niveles de análisis, diseño, codificación, verificación y validación, para
asegurar la confiabilidad.

Durante la etapa de planeación se deben considerar las fallas que el programa

pudiera presentar, debido a que de ello dependen usuarios , o productos y esto
puede ocasionar grandes pérdidas, o poner la vida en peligro si es que el
programa está integrado para una actividad que maneje actividades relacionadas
directamente con dispositivos de personal, como puede ser un elevador.

2.5. Principios de estimación

La estimación depende de diversos factores tales como:

 Complejidad del proyecto

 Tamaño del proyecto
 Estabilidad de los requisitos
 Facilidad de identificar funciones
 Estructura de la información
 Disponibilidad de información histórica

Existen principios que deben estar presentes en la estimación:

 Retrasar la estimación lo más que se pueda, esto debido a que de acuerdo

al atraso que se tenga más precisa será.
 Realizar la estimación por analogía. Esto es que se pueden basar en
proyectos anteriores y similares.
  Aplicar la ley de Parkinson. Esto es que el trabajo se extienda para rellenar
el tiempo disponible.
 Precio para ganar. El coste del proyecto debe estimarse en base al dinero
que el cliente piensa gastar en el proyecto.
 Técnicas de descomposición. Para ello el proyecto debe de descomponerse
y estimar el costo pro producto o proceso o ambos.
 Modelos empíricos. Esto se refiere a los modelos de regresión, los cuales
relacionan esfuerzo con el tamaño o la funcionalidad del proyecto.

2.6. Métodos de estimación populares

2.6.1 El método FuzzyLogic.

Este método es la ciencia que estudia las leyes, los modos y las formas del
razonamiento aproximado.

Características:

 Soporta datos imprecisos

 Es conceptualmente fácil de entender
 Es flexible
 Es tolerante a los datos imprecisos
 Se basa en el lenguaje humano
 Se basa en la experiencia de expertos conocedores del problema en
cuestión
 Puede modelar funciones no lineales de alguna complejidad
 Combina en forma unificada expresiones lingüísticas con datos numéricos1

2.6.2 Método de estimación por puntos de función

Este método se originó en los años 70’s, para predecir el esfuerzo necesario para
el desarrollo de un proyecto de software.

1
Hernández Ortega, S. (26 de Mar de 2012). http://es.slideshare.net. Recuperado el 13 de Feb de
2015, de Lógica Difusa: http://es.slideshare.net/CrypticHernndezOrtega/lgica-difusa-fuzzy-logic
Los puntos de función permanecen constantes, y son independientes de la
tecnología que se utilizará, del método de desarrollo y la plataforma que se
emplearán para el desarrollo del proyecto.

La aplicación de este método también apoya en la evaluación y comparación de

las herramientas, o lenguajes.

Por medio de los requisitos de las LDC (Líneas de código) es más sencillo
determinar el tamaño del programa.

El número de puntos de función de un programa se basa en el número y

complejidad de los elementos siguientes:

Elemento Abreviaturas Descripción Ejemplos

por medio de ellos el Pantallas, formularios
Entradas
usuario final puede de captura, cuadros
EI
añadir, borrar, modificar de dialogo mensajes,
datos del programa
Incluye cualquier salida Pantallas, informes,
que se tenga en un gráficas o mensajes
Salidas EO formato diferente a otros que el programa
tipos de salida genera para el
usuario
Consultas que pueden Las consultas
ser de entrada o salida recuperan datos de
interactiva simple o las bases de datos y
Peticiones EQ
inmediata muestran solo lo que
se solicita en la
consulta o petición
Son archivos que están Puede ser un archivo
bajo el control de un único y plano (de
Archivos
programa a desarrollar. texto ASCII), o de
Lógicos ILF
una tabla de una
Internos
Base de datos
relacional
Son archivos Puede ser cualquier
controlados por otros archivo que salga o
Archivos de
programas, con los que entre al programa a
Interfaz EIF
el programa a desarrollar
Externos
desarrollar estará
interactuando

Tabla 1. Elementos de los puntos de función

 COMPLEJIDAD DE LAS ENTRADAS
No. Tipos de elementos de datos
No. Tipos de archivos
incluidos
referenciados
1-4 5 - 15 ≥ 16
0–1 Baja Baja Media
2–3 Baja Media Alta
≥4 Media Alta Alta

Tabla 2. Calibración de la complejidad de las entradas en Puntos de Función

COMPLEJIDAD DE LAS SALIDAS Y PETICIONES

No. Tipos de elementos de datos
No. Tipos de archivos
incluidos
referenciados
1-5 6 - 19 ≥ 20
0–1 Baja Baja Media
2–3 Baja Media Alta
≥4 Media Alta Alta

Tabla 3. Calibración de la complejidad de las salidas y peticiones en Puntos de Función

COMPLEJIDAD DE LOS ARCHIVOS E INTERFACES

No. Tipos de elementos de datos
No. Tipos de archivos
incluidos
referenciados
1 - 19 20 - 50 ≥ 51
0–1 Baja Baja Media
2–5 Baja Media Alta
≥6 Media Alta Alta

Tabla 4. Calibración de la complejidad de los archivos interfaces en Puntos de Función

PARÁMETRO DE MEDICIÓN FACTOR DE PONDERACIÓN

Cuenta Simple Medio Complejo
Número de
entradas de
usuario ____ X 3 4 6 =________
Número de salidas ____ X 4 5 7 =________
 de usuario
Número de
peticiones de
usuario ____ X 3 4 6 =________
Numero de
archivos ____ X 7 10 15 =________
Número de
interfaces
externas ____ X 5 7 10 =________
CUENTA TOTAL Ʃ = ______

Tabla 5. Cuenta total de los Puntos de Función

0 1 2 3 4 5
Sin influencia Incidental Moderado Medio Significativo Esencial

Tabla 6. Evaluación de los factores de complejidad en Puntos de Función

Las siguientes preguntas deben ser respondidas utilizando la escala de la tabla

anterior.

1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?+

2. ¿Se requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es crítico el rendimiento?
5. ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente
utilizado?
6. ¿Requiere el sistema entrada de datos interactiva?
7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada
se lleven a cabo múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de forma interactiva?
9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?
10. ¿Es complejo el procesamiento interno?
11. ¿Se ha diseñado el código para ser reutilizable?
12. ¿Están incluidas ene l diseño ña conversión y la instalación?
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en
diferentes organizaciones?
14. ¿Se ha diseñado la ap0licación para facilitar los cambios y ser fácilmente
utilizada por el usuario?
Productividad = PF/persona – mes

Calidad = errores / PF

Costo = Pesos / PF

Documentación = Págs. Doc. /PF

Características del sistema a

medir y de su entorno de Pro
ce
cá so d
Puntos de Función
de lculo e
desarrollo PF
calc sin
sin ajustar Puntos de función
ula
r sin ajustar

Jefe de Proyecto/ Gerente

del sistema / Persona
encargada de realizar las
estimaciones del proyecto de Herramienta de software
software

Pr
de oces
de cálcu
o Puntos de Función
Puntos de Función l
de facto
lo
aju r
ste ajustados
sin ajustar Puntos de función
Puntos de función sin ajustados
ajustar

Puntos de Función Líneas de código

ajustados Transformación de estimadas (LOC) Líneas de código
Puntos de función puntos de función estimadas (LOC)
ajustados en LOC

Ilustración 1. Proceso de cálculo de PF y transformación en líneas de código

2.6.3 Método del componente estándar

Este método mantiene una base de datos con la información de los componentes
usados en proyectos pasados, la información almacenada está dividida en niveles
como:

 Subsistemas completos
 Módulos
 Interfaces de usuarios
 Códigos
 Entre otros

Para conocer cuántos componentes estándar tendrá un proyecto se realiza una

estimación de componentes en un máximo y mínimo, todo ello se multiplica 4
veces y se le suman el máximo más el mínimo y se divide entre 6, tal como lo
muestra la ilustración 2.

(4 * est + máx + mín) / 6

Ilustración 2. Fórmula para calcular los componentes estándares

Algunas consideraciones que se deben tener al utilizar el método de componentes

estándar son:

 Los modelos teóricos de estimación son útiles pero cuentas con varias
limitaciones
 De acuerdo a las técnicas de medición y estimación muchas veces se
compromete el proyecto en plazos imposibles, desde un inicio.
 Algunas veces el tiempo de desarrollo de un proyecto es fijado por personal
ajeno al proyecto, por lo cual no se realiza ningún cálculo serio.
 El ingeniero o jefe del proyecto debe ser claro desde un inicio en cuanto a
la asignación y tiempos de resultados y defender los tiempos para alcanzar
el objetivo.
 Jefe del proyecto alguna veces no realiza estimaciones de tiempo y costo y
esto puede ocasionar problemas durante el desarrollo del proyecto
 Lo ideal es desarrollar un modelo de estimación propio utilizando la
información histórica de la misma empresa.
2.6.4 Método Delphi

1. Es necesario contar con la documentación con la definición del sistema y

la papeleta para la estimación del sistema, como se muestra en la
ilustración 3.

Sistema para consultas Fecha: 15-Feb-2015

Estimación en la 3a vuelta: X

Su estimación es: X
Meses - Programador

0 20 40 60 80 100

Su estimación para la siguiente vuelta es : 35 PM

Razones para su estimación:

*Parece un sistema normal de control de procesos

*Nuestra gente ha tenido gran experiencia en proyectos similares
*No se espera que haya problemas con este proyecto

Ilustración 3. Ejemplo de papeleta para la estimación

2. Cada experto estudia y define su estimación cada uno de ellos puede tratar
y consultar su estudio con el coordinador, pero no entre ellos.
3. El coordinador brinda un resumen de las estimaciones realizadas por los
expertos, incluyendo todo aquella estimación extraña.
4. Los expertos realizan un asegunda estimación tomando en cuenta el
resumen de la estimación anterior, y caso de que la segunda vuelta de las
estimaciones realizadas por cada uno de la expertos setos rea diferente a la
 primera se le solicitará al experto que realice una justificación de su
estimación.
5. El proceso se puede repetir cuantas veces sea necesario, esto para evitar
alguna discusión grupal durante el tiempo que lleve el proceso.

2.6.5 Método de puntos de casos de uso

El método de casos de uso permite documentar los requisitos de un

sistema en términos de actores y casos de uso, proporcionando uno o más
escenarios que indican cómo debería interactuar el sistema con el usuario o con
otro sistema para conseguir un objetivo específico. Debido a la importancia de
esta técnica en el análisis orientado a objetos para capturar y describir los
requisitos funcionales de un sistema, surgió la necesidad de desarrollar un
método de cálculo del tamaño funcional específicamente diseñado para esta
técnica [CUAD08]. El método “Puntos de Casos de Uso”, como se mencionó en la
introducción lo obtuvo Gustva Karner en 1993 y posteriormente fue refinado por
varios autores.

Por tanto, la estimación mediante el análisis de Puntos de Casos de

Uso, consiste en un método de estimación del tiempo de desarrollo de un
proyecto mediante la asignación de “pesos” a un cierto número de factores que lo
afectan, para que luego a partir de esos factores se pueda contabilizar el tiempo
total estimado para el proyecto en cuestión. [PERA09]

En la siguiente figura, se pueden observar los principales pasos del método

Estimación Puntos de Casos de Uso.
Calculo de los puntos

El primer paso para la estimación consiste en el cálculo de los Puntos

de Casos de Uso sin ajustar. Este valor, se calcula a partir de la siguiente
ecuación:

UUCP = UAW + UUCW

UUCP: Puntos de Casos de Uso sin ajustar

UAW: Factor de Peso de los Actores sin ajustar
UUCW: Factor de Peso de los Casos de Uso sin ajustar

A continuación se describen cómo obtener los factores de peso

relacionados a los actores y casos de uso respectivamente, para que
posteriormente se pueda obtener los Puntos de Casos de Uso sin ajustar.
Factores de peso de los Actores sin ajustar

Para obtener el valor del factor de Peso de los casos de uso, se calcula la cantidad de
casos de uso presentes en el sistema y la complejidad de cada uno de ellos.

La complejidad de los casos de uso se establece teniendo en cuenta el tipo de caso de

uso, pudiendo ser éste: simple, medio y complejo; así como también teniendo en cuenta el número
de transacciones efectuadas en el mismo. Se entiende transacción [GAGA09] por el conjunto de
actividades atómicas, que se pueden ejecutar ya sean todas de forma completa o ninguna.

La siguiente tabla, muestra los criterios a tener en cuenta para clasificar los casos de uso:

Tipo de Caso
Descripción Peso
de Uso
Simple El caso de Uso contiene menos de 3
5
transacciones
Medio El caso de Uso contiene de 4 a 7
10
transacciones
Complejo El caso de uso tiene más de 7
15
transacciones

Tabla 2 - Clasificación de los Casos de Uso

La clasificación de los casos de uso permite conocer el valor del UUCW (Unadjusted Use
Case Weights) de manera análoga al caso anterior, mediante el conteo del número de casos de
uso en cada tipo, multiplicando éstos por el factor de ajuste correspondiente y realizando la suma
de los resultados.

UUCW = L (TipoCasoDeUso¡*Peso¡)
Cálculo de Puntos de Casos de Uso ajustados

Una vez que se tienen los Puntos de Casos de Uso sin ajustar, se debe
ajustar ese valor mediante factores de ajuste, tanto técnicos como de ambiente,
haciendo uso de la siguiente ecuación:

UCP = UUCP * TCF * EF

Donde,
UCP: Puntos de Casos de Uso ajustados
UUCP: Puntos de Casos de Uso
sin ajustar TCF: Factor de
complejidad técnica
EF: Factor de ambiente

Se debe tener en cuenta que a través del cálculo de esta expresión

obtenemos una estimación del tamaño y no del esfuerzo [GAGA09]. El cálculo de
la estimación del esfuerzo se detallará en el punto 3.3.

Factor de Complejidad Técnica (TCF)

El coeficiente se calcula mediante la cuantificación de un conjunto de

factores que determinan la complejidad técnica del sistema. Cada uno de los
factores se cuantifica con un valor de 0 al 5, donde:
Un valor de 0 significa que el factor es
irrelevante. Un valor de 3 significa que el
factor es promedio. Un valor de 5
significa que el factor es esencial.

Dichos valores varían de acuerdo con la complejidad del proyecto.

 Una vez que todos los factores técnicos tienen asignados el valor de
influencia, se procede al cálculo de los resultados de cada factor, es decir, se
realiza una multiplicación entre la influencia (valor asignado) y su peso asociado.
Conforme se puede visualizar en la siguiente tabla:

Resultad
Factor Descripción Peso Influencia o

F1 Sistema Distribuido 2 n1 2*n1

Tiempo de Respuesta y
F2 Desempeño 1 n2 1*n2

F3 Eficiencia respecto al usuario final 1 n3 1*n3

F4 Procesamiento interno complejo 1 n4 1*n4

Código reutilizable en otras

F5 aplicaciones 1 n5 1*n5

F6 Facilidad en la instalación 0,5 n6 0,5*n6

Influenci Resultad
Factor Descripción Peso a o

F7 Usabilidad (Fácil de usar) 0,5 n7 0,5*n7

F8 Portabilidad 2 n8 2*n8

F9 Facilidad en mantener 1 n9 1*n9

F10 Acesos simultáneos (concurrentes) 1 N10 1*n10

Incluye objetivos especiales de

F11 seguridad 1 N11 1*n11

F12 Provee acceso directo a terceros 1 N12 1*n12

 Se requiere facilidades especiales
de N13 1*n13
F13 1
entrenamiento a usuarios

Tabla 3 – Cálculo de los Factores Técnicos

Karner, G. (1993) y Schneider, G.; Winters, J. P. (2001, p. 154),

Por tanto, el factor de complejidad técnica se calcula mediante la siguiente

ecuación:

TCF = 0.6 + 0.01 * V (Peso¡ * Valor asignado¡)

A continuación, el significado de cada uno de los factores, mencionados en

la tabla anterior, los mismos fueron descritos por [DOSS09]:

F1 - Sistema Distribuido

La arquitectura puede ser centralizada como también distribuida.

- 0: La aplicación no auxilia en la transferencia de datos o procesos

entre CPUs.
- 1: La Aplicación prepara datos para que el usuario final los procese
en otra CPU. Ejemplo: planillas electrónicas o gestores de bases de
datos.
- 2: Los datos son preparados para ser transferidos y procesados en
otra CPU.
- 3: Procesamiento distribuido y transferencia de datos online en una
dirección.
- 4: Procesamiento distribuido y transferencia de datos online en
ambas direcciones.
- 5: Las funciones de procesamiento son ejecutadas dinámicamente
en la CPU más apropiada.
F2 - Tiempo de Respuesta y Desempeño

Identifica los objetivos de Desempeño de la aplicación, establecidos y

aprobados por el
usuario.
- 0: Ninguna exigencia especial de desempeño fue establecida por el
usuario.
- 1: Requisitos de desempeño fueron establecidos y revisados por el
usuario, pero ninguna acción especial fue necesaria.
- 2: El tiempo de respuesta es crítico durante horas pico. El intervalo
de tiempo límite (deadline) del procesamiento es siempre para el
próximo día útil. Ninguna consideración especial para la utilización
de la CPU fue requerida.
- 3: El tiempo de respuesta es crítico durante todo el tiempo de
utilización de la aplicación. Los requisitos de plazo de procesamiento
con otros sistemas son limitados. No fue necesario ningún
procedimiento especial para la utilización de la CPU.
- 4: Los requisitos de desempeño establecidos por el usuario son
rigurosos y bastante para requerir tareas de análisis de desempeño
en la fase de análisis y proyecto de la aplicación.
- 5: Además de lo descrito en el ítem 4, herramientas de análisis de
desempeño fueron usadas en las fases de proyecto, desarrollo y/o
implementación con el fin de proporcionar el desempeño establecido
por el usuario.

F3 - Eficiencia respecto al Usuario Final

Las funciones proporcionadas, enfatizan una aplicación para la eficiencia

del usuario final. Ejemplo: menú, documentación de ayuda online, movimiento
automático del cursor, movimiento del la pantalla (scrolling) vertical y horizontal,
teclas de función predefinidas, facilidad navegación entre pantallas, número
mínimo de pantallas para ejecutar una función de negocio, impresiones remotas,
soporte multilingüe (más de dos idiomas), entre otras.

- 0: La aplicación no presenta ninguno de los ítems mencionados

anteriormente.
- 1: Presenta 1 a 3 de los ítems mencionados arriba.
- 2: Presenta 4 a 5 de los ítems mencionados arriba.
- 3: Presenta 6 o más de los ítems mencionados arriba, pero no hay
ningún requisito relacionado a la eficiencia.
- 4: Presenta 6 o más de los ítems mencionados arriba, y los
requisitos establecidos para la eficiencia son riguroso y suficientes
para que la fase de proyecto de la aplicación incluya factores para
minimizar la digitación, maximizar los defaults, utilizar templates,
entre otros.
- 5: Presenta 6 o más de los ítems mencionados anteriormente, y los
requisitos establecidos para la eficiencia del usuario son rigurosos o
suficientes para que sea necesario el uso de herramientas y
procesos especiales para demostrar que los objetivos de eficiencia
fueron alcanzados.

F4 - Procesamiento Interno Complejo

La complejidad de procesamiento tiene influencia en el dimensionamiento

del sistema, y, por tanto, debe ser cuantificado el grado de influencia con base en
las siguientes categorías:
Procesamiento especial de auditoría y/o procesamiento especial
de seguridad. Procesamiento lógico extensivo.
 Procesamiento matemático extensivo.
Gran cantidad de procesamiento de ejecución, resultante de transacciones
incompletas que necesitan de reprocesamiento. Por ejemplo: transacciones
incompletas de ATM (cajeros automáticos) causados por interrupciones de
comunicación, valores de datos ausentes o validaciones de errores.
Procesamiento complejo para manipular múltiples posibilidades de
entrada/salida. Por ejemplo: múltiples medios e independencia de
equipos.

- 0: No presenta ningún item mencionado anteriormente.

- 1: Presenta uno de los ítems de arriba.
- 2: Presenta dos de los ítems de arriba.
- 3: Presenta tres de los ítems de arriba.
- 4: Presenta cuatro de los ítems de arriba.
- 5: Presenta todos los ítems mencionados en el párrafo anterior.

F5 - Código Reutilizable en otras Aplicaciones

La aplicación y su código fuente, fueron específicamente proyectados,

desarrollados y soportados para que sean reutilizables en otras aplicaciones.

- 0: No presenta código reutilizable.

- 1: El código reutilizable es usado solamente dentro de la aplicación.
- 2: Menos del 10% de la aplicación fue hecha, teniendo en cuenta su
utilización en otras aplicaciones.
- 3: 10% o más de la aplicación fue hecha, teniendo en cuenta su
utilización en otras aplicaciones.
- 4: La aplicación fue proyectada y documentada para facilitar la
reutilización de código y la aplicación es personalizada por el usuario
a nivel de código fuente.
- 5: La aplicación fue proyectada y documentada para facilitar la
 reutilización del código fuente.

F6 - Facilidad en la Instalación

Indica el nivel de preparación de procedimientos y herramientas para la

instalación del sistema.
- 0: Ninguna consideración se ha tenido en cuenta por el usuario y
ningún procedimiento especial fue requerido para la instalación.
- 1: Ninguna consideración especial se ha tenido en cuenta por el
usuario, pero un procedimiento especial fue requerido para la
instalación.
- 2: Requisitos de instalación fueron establecidos por el usuario.
- 3: Requisitos de instalación fueron fijados por el usuario y scripts de
instalación fueron preparados y probados.

- 4: Además de lo descrito en el ítem 2, herramientas automatizadas

de instalación fueron preparadas y probadas.
- 5: A demás de los descrito en el ítem 3, herramientas automatizadas
de instalación fueron preparadas y probadas.

F7 - Usabilidad

Procedimientos efectivos de instalación, backup y recuperación fueron

desarrollados y probados. La aplicación minimiza la necesidad de actividades
manuales.

- 0: Ninguna consideración especial sobre la facilidad operacional,

además de los procedimientos normales de backup, fue tenida en
cuenta por el usuario.
- 1: Procedimientos eficientes de inicialización, backup y recuperación
fueron preparados, pero la intervención del operador es necesaria.
- 2: Procedimientos eficientes de inicialización, backup y recuperación
 fueron preparados, pero ninguna intervención del operador es
necesaria.
- 3: La aplicación minimiza la operación de montaje de cintas
magnéticas.
- 4: La aplicación minimiza la necesidad de manoseo de formularios.
- 5: La aplicación fue proyectada de manera que ningún operador
intervenga en el funcionamiento normal.

F8 - Portabilidad

La aplicación fue específicamente proyectada, desarrollada y soportada

para ser instalada en múltiples plataformas (Windows, Unix, Linux…).

- 0: El usuario no ha solicitado considerar la necesidad de instalar la

aplicación en más de una plataforma.
- 1: La necesidad de instalación en múltiples plataformas fue llevada
en consideración en el proyecto y la aplicación fue proyectada para
operar solamente en ambientes idénticos de hardware y software.
- 2: La necesidad de instalación en múltiples plataformas fue llevada
en consideración en el proyecto y la aplicación fue proyectada para
operar solamente en ambientes similares de hardware y software.
- 3: La necesidad de instalación en múltiples plataformas fue llevada
en consideración en el proyecto y la aplicación fue proyectada para
operar en ambientes diferentes.
- 4: Un plan de documentación y mantenimiento fue elaborado y
probado para soportar la aplicación en múltiples plataformas y la
aplicación atiende los ítems 1 y 2.
- 5: Un plan de documentación y mantenimiento fue elaborado y
probado para soportar la aplicación en múltiples plataformas si la
aplicación atiende el ítem 3.
F9 - Fácil de Mantener

La aplicación fue específicamente proyectada, desarrollada para soportar

el mantenimiento, garantizando la facilidad de cambios.

- 0: No fue considerado por el usuario, ningún requisito especial para

proyectar la aplicación que garantice minimizar o facilitar los
cambios.
- 1: Recursos de consultas/informes flexibles son proporcionados, de
manera que sea capaz de manipular solicitudes simples de consulta
(Query/requests). Ejemplo: Lógica de and or aplicada solamente aun
Archivo Lógico Interno (contar como un ítem).
- 2: Recursos de consultas/informes flexibles son proporcionados, de
manera que sea capaz de manipular solicitudes de consulta
(Query/requests) de complejidad media. Ejemplo: Lógica de and/or
aplicada a más de un Archivo Lógico Interno (contar como dos
ítems).
- 3: Recursos de consultas/informes flexibles son proporcionados, de
manera que sea capaz de manipular solicitudes consulta
(Query/requests) complejas. Ejemplo: Combinaciones de lógica de
and/or aplicadas a uno o más de un Archivo Lógico Interno (contar
como tres ítems).
- 4: Datos de control son mantenidos en tablas que son actualizadas
por el usuario a través de procesos online e iterativos, pero las
alteraciones sólo son actualizadas por el usuario a través de
procesos online e iterativos, pero las modificaciones sólo son
efectivas en el próximo día útil.
- 5: Datos de control son mantenidos en tablas que pueden ser
actualizadas por el
usuario a través de procesos online e iterativos, y las modificaciones
son efectivizadas inmediatamente (contar como dos ítems).
F10 - Accesos Simultáneos (Concurrentes)

Indica el volumen de acceso simultáneo a la aplicación.

- 0: No es esperado acceso simultáneo.

- 1: Son esperados accesos simultáneos esporádicamente.
- 2: Accesos simultáneos son esperados.
- 3: Accesos simultáneos son esperados diariamente.
- 4: Muchos accesos simultáneos fueron fijados por el usuario para la
aplicación, lo que fuerza la ejecución de tareas de análisis de
desempeño en la fase de proyecto de la aplicación.
- 5: Requiere el uso de herramientas que controlen el acceso en las
fases de desarrollo e implementación, además de las
consideraciones anteriores.

F11 - Características Especiales de Seguridad

Indica el nivel de seguridad exigido por la aplicación.

- 0: Ningún requisito por parte del usuario fue solicitado para

considerar la necesidad de control de seguridad en la aplicación.
- 1: Fue considerada en el proyecto del sistema, la necesidad de
control de seguridad.
- 2: Fue considerada en el proyecto del sistema, la necesidad de
control de seguridad y la aplicación fue proyectada para que
solamente usuarios autorizados puedan acceder.
- 3: Fue considerada en el proyecto del sistema, la necesidad de
control de seguridad y la aplicación fue proyectada para que
solamente usuarios autorizados puedan acceder. El acceso será
controlado y auditado.
- 5: Un plan de seguridad fue elaborado y probado para soportar el
 control de acceso a la aplicación y una auditoría.

F13 - Entrenamiento a los Usuarios

Indica el nivel de facilidad de proveer capacitación a los usuarios para

utilizar el software.

- 0: Ningún pedido por parte del usuario para considerar la necesidad

de entrenamiento especial.
- 1: La necesidad de capacitación especial, fue llevada en
consideración en el proyecto del sistema.
- 2: La necesidad de capacitación fue llevada en consideración en el
proyecto del sistema y una aplicación fue proyectada para que los
usuarios puedan acceder con facilidad.
- 3: La necesidad de capacitación especial, fue llevada en
consideración en el proyecto del sistema y una aplicación fue
proyectada para que los usuarios pueda utilizar en diversos niveles
- 4-5: Un plan de capacitación fue elaborado y probado para facilitar el
uso de la aplicación.

Factores de Ambiente (EF)

Además de tener en cuenta los factores técnicos para el ajuste de los

UUCP (Puntos de Casos de Uso no ajustados), se contabilizan los factores de
ambiente. De manera similar al cálculo de los TCF, a cada factor de ambiente
definido en la siguiente tabla, se la asignan valores entre el 0 y el 5.

Una vez que todos los factores de ambiente tienen asignado el valor de la
influencia, se procede al cálculo de los resultados de cada factor, es decir, se
realiza una multiplicación entre la influencia del factor y su peso asociado.
 En la siguiente tabla se presenta un resumen del procedimiento del cálculo
de los factores de ambiente, siendo Ei los factores concretos.

Pes
Factor Descripción o Influencia Resultado

Familiarizado con el proceso de

E1 1,5 n1 R1=1,5*n1
desarrollo (RUP)

E2 Experiencia en la aplicación 0,5 n2 R2=0,5*n2

Experiencia en orientación a
E3 objetos 1 n3 R3=1*n3

E4 Capacidades de análisis 0,5 n4 R4=0,5*n4

E5 Motivación 1 n5 R5=1*n5

E6 Requisitos estables 2 n6 R6=2*n6

E7 Trabajadores a tiempo parcial -1 n7 R7=-1*n7

E8 Lenguaje complejo -1 n8 R8=-1*n8

Tabla 4 - Cálculo los Factores de Ambiente

- Para los factores E1 al E4, un valor asignado de 0 significa sin

experiencia, 3 experiencia media y 5 amplia experiencia (experto).
- Para el factor E5, 0 significa sin motivación para el proyecto, 3
motivación media y 5 alta motivación.
- Para el factor E6, 0 significa requisitos extremadamente inestables, 3
estabilidad media y 5 requisitos estables sin posibilidad de cambios.
- Para el factor E7, 0 significa que no hay personal tiempo parcial (es
decir todos son de tiempo completo), 3 significa mitad y mitad (es
decir, la empresa cuenta con personal que trabaja, medio período y
otros tiempo completo), y 5 significa que todo el personal trabaja
medio período (nadie período completo).
 - Para el factor E8, 0 significa que el lenguaje de programación es fácil
de usar, 3 medio y 5 que el lenguaje es extremadamente difícil.

Cuando se han calculado los resultados de cada uno de los factores, se

aplica la ecuación descrita a continuación:

EF = 1.4 – 0.03 * V (Peso¡ * Valor asignado¡)

2.6.6 Estimación basada en Proxies.

Las buenas medidas de tamaño son aquellas que son detalladas, y en los
estimadores iniciales rara vez se puede pensar en detalle.

Algunas alternativas es esperar hasta tener detalle, realizar las mejores

estimaciones e identificar un proxy ajustable.

Un buen proxy debe correlacionar los costes de desarrollo, podría ser fácil
presentarlo al comienzo del desarrollo, debe ser una entidad física contable.

Ejemplos de Proxies:

 Puntos de Función
 Objetos
 Elementos del Producto
o Componentes
o Pantallas
o Informes
o Scripts
o Ficheros
o Capítulos de libro

Los puntos de función como se menciona anteriormente también son

considerados Proxies.

Ya que los datos muestran que la cuenta de puntos de función correlacionan

bien con el tiempo de desarrollo, además pueden ser presentados al principio
del desarrollo, para usar los PF de forma apropiada se necesitan estimadores
bien entrenados.

Los PF, no pueden ser contados de modo inmediato, los factores de

conversión están disponibles para contar LOC y calcular los PF a partir del valor
de LOC.

El grupo de usuarios de PF están continuamente refinando el método.