Calculations From Other Tabs

TCF Factor de complejidad técnica 1.015

EF Factor medioambiental 0.89

UUCP Puntos de casos de uso no ajustados 30

AW Ponderación del actor 9
Calculation of Use Case Points

UCP Puntos de casos de uso 35.2

Calculation of Estimated Effort

Horas de esfuerzo por punto de caso

Ratio de uso 28

Hours of Effort 986

Steps to Calculate Use Case Points

0 For all tabs, enter values only in the highlighted cells
1 Enter Technical Complexity Factors on the Technical tab
2 Enter Environemental Factors on the Environmental tab
3 Identify Use Cases on the Use Case tab
4 Identify Actors on the Actor tab
 Relative
Technical Factor Multiplier Magnitude
(Enter 0-5)

1 Requiere sistema 2 3
distribuido

El tiempo de
2 respuesta es 1 5
importante

3 Eficiencia del 1 4
usuario final

Se requiere
4
procesamiento
1 3
interno complejo

El código
5 reutilizable debe 1 3
ser un enfoque

6 Facilidad de 0.5 4
instalación
7 Usabilidad 0.5 5
Soporte
8
multiplataforma
2 0

9
Fácil de cambiar
1 4

Altamente
10
concurrente
1 3

Seguridad
11
personalizada
1 3
 Dependencia del
12
código de terceros
1 3

13 Entrenamiento de 1 3
usuario
Calculated TCF 1.015
 Description

La arquitectura de la solución puede ser centralizada o de un solo inquilino,

o puede ser distribuida (como una solución de n niveles) o multi-inquilino.
Los números más altos representan una arquitectura más compleja.

La rapidez de respuesta de los usuarios es un factor importante (y no

trivial). Por ejemplo, si se espera que la carga del servidor sea muy baja,
esto puede ser un factor trivial. Los números más altos representan una
importancia creciente del tiempo de respuesta (un motor de búsqueda
tendría un número alto, un agregador de noticias diario tendría un número
bajo).

¿Se está desarrollando la aplicación para optimizar la eficiencia del usuario

o solo la capacidad? Los números más altos representan proyectos que
dependen más de la aplicación para mejorar la eficiencia del usuario.

¿Hay mucho trabajo algorítmico difícil de hacer y probar? Los algoritmos

complejos (nivelación de recursos, análisis de sistemas en el dominio del
tiempo, cubos OLAP) tienen números más altos. Las consultas de bases
de datos simples tendrían un número reducido.
¿Es la reutilización de código pesado un objetivo o meta? La reutilización
de código reduce la cantidad de esfuerzo necesario para implementar un
proyecto. También reduce la cantidad de tiempo necesario para depurar un
proyecto. Una función de biblioteca compartida se puede reutilizar varias
veces, y corregir el código en un solo lugar puede resolver varios errores.
Cuanto mayor sea el nivel de reutilización, menor será el número.
¿Es la facilidad de instalación para los usuarios finales un factor clave?
Cuanto mayor sea el nivel de competencia de los usuarios, menor será el
número.
¿Es la facilidad de uso un criterio principal de aceptación? Cuanto mayor
sea la importancia de la usabilidad, mayor será el número.
¿Se requiere soporte multiplataforma? Cuantas más plataformas deban ser
compatibles (esto podría ser versiones de navegador, dispositivos móviles,
etc. o Windows / OSX / Unix), mayor será el valor.
¿El cliente requiere la capacidad de cambiar o personalizar la aplicación en
el futuro? Cuanto más cambio / personalización se requiera en el futuro,
mayor será el valor.

¿Tendrá que abordar el bloqueo de la base de datos y otros problemas de

concurrencia? Cuanta más atención tenga que dedicar a la resolución de
conflictos en los datos o la aplicación, mayor será el valor.

¿Se pueden aprovechar las soluciones de seguridad existentes o se debe

desarrollar un código personalizado? Cuanto más trabajo de seguridad
personalizado tenga que hacer (nivel de campo, nivel de página o
seguridad basada en roles, por ejemplo), mayor será el valor.
¿La aplicación requerirá el uso de bibliotecas o controles de terceros? Al
igual que el código reutilizable, el código de terceros puede reducir el
esfuerzo necesario para implementar una solución. Cuanto más código de
terceros (y más confiable sea el código de terceros), menor será el
número.
¿Cuánta formación de usuario se requiere? ¿La aplicación es compleja o
admite actividades complejas? Cuanto más tarden los usuarios en cruzar
el umbral de succión (alcanzar un nivel de dominio del producto), mayor
será el valor.
 Relative
Environmental Factor Multiplier Magnitude
(Enter 0-5)

Familiaridad con el
1
proyecto
1.5 4

Experiencia de
2
aplicación
0.5 4

Experiencia de
3
programación OO
1 3

4 Capacidad de 0.5 4
analista líder

5 Motivación 1 3

6 Requisitos 2 5
estables

7 Personal a tiempo -1 4
parcial

Lenguaje de
8
programación
-1 5
difícil
Calculated EF 0.89
 Description

¿Cuánta experiencia tiene su equipo trabajando en este dominio? El

dominio del proyecto será un reflejo de lo que se pretende lograr con el
software, no el lenguaje de implementación. En otras palabras, para un
sistema de compensación de seguros escrito en Java, a usted le importa la
experiencia del equipo en el espacio de compensación de seguros, no la
cantidad de Java que hayan escrito. Los niveles más altos de experiencia
obtienen un número más alto.
Cuánta experiencia tiene su equipo con la aplicación. Esto solo será
relevante al realizar cambios en una aplicación existente. Los números
más altos representan más experiencia. Para una nueva aplicación, la
experiencia de todos será 0.
¿Cuánta experiencia tiene su equipo en OO? Puede ser fácil olvidar que
muchas personas no tienen experiencia en programación orientada a
objetos si estás acostumbrado a tenerla. Un proyecto centrado en el
usuario o basado en casos de uso tendrá una estructura inherentemente
OO en la implementación. Los números más altos representan más
experiencia OO.
¿Qué conocimientos y capacidad tiene la persona responsable de los
requisitos? Los malos requisitos son el asesino número uno de los
proyectos: Standish Group informa que entre el 40% y el 60% de los
defectos provienen de los malos requisitos. Los números más altos
representan una mayor habilidad y conocimiento.

¿Qué tan motivado está tu equipo? Los números más altos representan
más motivación.
Los cambios en los requisitos pueden provocar aumentos en el trabajo. La
forma de evitar esto es planificar el cambio e instituir un sistema de tiempo
para gestionar esos cambios. La mayoría de la gente no hace esto, y
algunas modificaciones serán inevitables. Los números más altos
representan más cambios (o un sistema menos efectivo para gestionar el
cambio).
Tenga en cuenta que el multiplicador de este número es negativo. Los
números más altos reflejan miembros del equipo que trabajan a tiempo
parcial, consultores externos y desarrolladores que dividen su tiempo en
proyectos. El cambio de contexto y otros factores intangibles hacen que
estos miembros del equipo sean menos eficientes.
Este multiplicador también es negativo. Los idiomas más difíciles
representan números más altos. Creemos que la dificultad está en el ojo
del codificador (gemido). Java puede ser difícil para un programador de
Fortran. Piense en ello en términos de dificultad para su equipo, no
dificultad abstracta.
 Unadjusted Number of
Multiplier
Use Case Points Use Cases
1 Simple 5 1
2 Medio 10 1
3 Complejo 15 1
Calculated UUCP 30

Individual Use Cases Multiplier Use Case Name

1 Simple 5 Validacion de usuario
2 Medio 10 Cambio operario
3 Complejo 15 Cuadricula
Insert additional rows above this row and copy the cell values to automatically update the counts
 Description
Simple Use Case - up to 3 transactions.
Average Use Case - 4 to 7 transactions.
Complex Use Case - more than 7 transactions.

Use Case Name

dacion de usuario
mbio operario
dricula
opy the cell values to automatically update the counts of actors by type
 Number of
Actor Summary Multiplier
Actors

1 Simple 1 2

2 Medio 2 2

3 Complejo 3 1

Calculated AW 9

Individual Actors Multiplier Actor Name

1 Simple 1 API rest Tiempo
2 Medio 2 E-Commerce
3 Complejo 3 Usuario
4 Simple 1 Validaciones
5 Simple 1 Ingreso de datos
Insert additional rows above this row and copy the cell values to automatically update the counts
 Description

Los actores simples son otros sistemas que se comunican con su software
a través de una API predefinida. Una API podría exponerse a través de
una dll, o como REST, SOAP o cualquier API de servicio web o llamada a
procedimiento remoto (RPC). El elemento clave es que está exponiendo la
interacción con su software a través de un mecanismo específico y bien
definido.
Los actores promedio pueden ser seres humanos que interactúan en un
protocolo bien definido o pueden ser sistemas que interactúan a través de
una API más compleja o flexible.

La definición original de actores complejos especifica que los usuarios que

interactúan con el software a través de una interfaz gráfica de usuario son
actores complejos. Si bien eso es cierto, la misma clasificación debería
aplicarse a los usuarios que interactúan con el sistema de formas
impredecibles. Una interfaz AJAX que expone más de la aplicación
subyacente (y almacenes de datos) de lo que estaría disponible a través
de un protocolo rígido podría introducir una complejidad similar.

Actor Name
rest Tiempo
ommerce
ario
daciones
eso de datos
opy the cell values to automatically update the counts of actors by type