PLANTILLA DE ESTIMACIÓN POR CASOS DE USO

Proyecto:

Factores de Peso con Ingrese el

relación a los Actores Descripción
del Sistema
Actor_Simple El actor representa otro sistema
que interactúa con el nuestro
mediante un API bien definido.
Valor
Peso Número Comentario
Ponderado
Total
Los actores simples son otros sistemas que se
comunican con nuestro software a través de una API
predefinida. Una API podría estar expuesta
mediante una dll, un servicio SOAP o cualquier API
web-service o remote procedure call (RPC). El
1
elemento clave es que estamos exponiendo
interacción con nuestro software a través de un
mecanismo específico y bien definido (Ej.
parámetros fijos).

Actor_Promedio El actor representa otro sistema
que interactúa con el nuestro a
través de un protocolo, tal como
TCP/IP.
Los actores promedio pueden ser tanto seres
humanos que interactúan con un protocolo bien
definido, o podrían ser sistemas que interactúan
2 mediante una API más compleja o más flexible
(ej.parámetros variables).

Actor_Complejo El actor es una persona que La definición original de actores complejos especifica
interacúa con nuestro sistema que los usuarios que interactúan con el software a
mediante una interface. través de una interface gráfica de usuario son
actores complejos. Si bien eso es cierto, la misma
clasificación debería aplicar para usuarios que
interactúan con el sistema de maneras
3 impredecibles. Una interface AJAX que expone más
de la aplicación subyacente (y bases de datos) de lo
que estaría disponible a través de un protocolo rígido
podría introducir una complejidad similar.

Peso Total de Actores

Factores de Peso de
Casos de Uso (Con Ingrese el
Valor
base en el número de Descripción Peso Número Comentario
Ponderado
comandos en un caso Total
de uso)
Caso_de_Uso_Simple 3 o menos comandos de usuario 5
Caso_de_Uso_Promedio 4 a 7 comandos de usuario 10 7 comandos de usuario
Caso_de_Uso_Complejo más de 7 comandos de usuario 15
Factores Basados en Comandos de usuario

Puntos de Casos de Uso no Ajustados

La Escala de
Factores de Peso Puntaje Valor
Puntuación es de 0 a Peso Razón
Técnicos Asignado Ponderado
5
T1 Sistema Distribuido 0 =no importante 5 =esencial La arquitectura de la solución podría ser centralizada
o stand-alone, o podría ser distribuida (como una
solución n-capas) o multi-servidor (servidor de
2 aplicaciones, servidor de base de datos). Los
números más grandes representan una arquitectura
más compleja.

T2 Objetivos de 0 =no importante 5 =esencial La rapidez de respuesta para los usuarios es un

factor importante (y no trivial). Por ejemplo, si se
desempeño o tiempos de espera que la carga del servidor sea muy baja, este
respuesta podría ser un factor trivial. Los números más
grandes representan una mayor importancia de los
1 tiempos de respuesta (un motor de búsqueda tendría
un número alto, un agregador de noticias diarias
tendría un número bajo).

T3 Eficiencia de Usuario 0 =no importante 5 =esencial La aplicación está siendo desarrollada para
optimizar la eficiencia del usuario, o solamente para
Final (online) añadir funcionalidad al sistema? Los números más
1 altos representan proyectos en los que hay una
fuerte expectativa de mejorar la eficiencia del
usuario.

T4 Procesamiento interno 0 =no importante 5 =esencial Hay gran cantidad de trabajo algorítmico difícil de
hacer y probar? Los algoritmos complejos
complejo (Asignación de recursos, cubos OLAP) tienen
1 números mayores. Los queries simples a una base
de datos tendrían números pequeños.

T5 El código debe ser 0 =no importante 5 =esencial Es primordial poder reutilizar el código que se
escriba en este proyecto? Reutilizar el código reduce
reutilizable la cantidad de esfuerzo requerido para desplegar un
proyecto. Una función de librería compartida puede
1 ser reutilizada varias veces, y arreglar el código en
un sólo lugar puede resolver múltiples bugs. A
mayor nivel de re-utilización requerida, mayor el
número asignado.

T6 Facilidad de 0 =no importante 5 =esencial La instalación del software (El proceso de hacerlo
disponible a los usuarios finales) es considerable? A
instalación mayor facilidad de hacer la instalación del sistema,
menor el número.

T7 Facilidad de uso 0 =no importante 5 =esencial Un criterio de aceptación primordial es la facilidad de

uso del software? A mayor importancia de la
usabilidad, mayor el número.

T8 Portabilidad 0 =no importante 5 =esencial Se requiere soporte multi-plataforma? A mayor

cantidad de plataformas deban ser soportadas (esto
podría incluir, versiones de navegador, diferentes
2 dispositivos móviles, etc, o S.O.
Windows/OSX/Unix), mayor el valor.

T9 Facilidad de hacer 0 =no importante 5 =esencial El cliente requiere la habilidad de poder cambiar o
personalizar la aplicación en el futuro? A mayor
cambios cantidad de cambios / personalización se requiera
1
en el futuro, mayor el valor.

T10 Concurrencia 0 =no importante 5 =esencial Tendremos que afrontar bloqueos de la base de
datos y otros problemas de concurrencia? A mayor
1 atención tengamos que prestar para resolver
conflictos en los datos o la aplicación, mayor el valor.

T11 Hay que incluir 0 =no importante 5 =esencial Se pueden reutilizar soluciones de seguridad (como
features especiales de autenticación y autorización para hacer operaciones
en el sistema) ya existentes, o es necesario
seguridad desarrollar código específico para garantizar que la
aplicacióne es segura? A mayor cantidad de código
1 de seguridad tengamos que hacer (a nivel de
campos, página o seguridad basada en roles, por
ejemplo), mayor el valor.

T12 Se utilizaran 0 =No se utiliza ningún La aplicación requerirá el uso de componentes o

componente externo 5 =Se librerías de terceros? Al igual que el código
componentes creados por utiliza un componente externo reutilizable, el código de terceros puede reducir el
terceros que realiza gran parte de la esfuerzo requerido para desplegar una solución. A
-1
funcionalidad requerida mayor cantidad de código de terceros a utilizar (y
más confiable sea este código), menor el número.

T13 Se requieren 0 =no importante 5 =esencial Qué tanto entrenamiento de usuario se requiere? La
aplicación es compleja, o soporta actividades
facilidades especiales complejas? Mientras más tiempo les tome a los
para entrenamiento a 1 usuarios llegar a dominar el uso del producto, mayor
usuarios el valor.

Factores Técnicos
Factor de Complejodad Técnica (TCF)
1
.06 + (.01*Factor Técnico)

Factores Ambientales La Escala de Estabilidad

Puntaje Valor
para el Equipo y Puntuación es de 0 a Peso de la Razón
Asignado Ponderado
Pesos 5 Experiencia
F1 Familiarizado con el 0 = sin experiencia, 3=promedio, Cuánta experiencia tiene nuestro
5=experto equipo trabajando en este
Proceso de Negocio dominio? El dominio del proyecto
será un reflejo de lo que el se
pretende que el software haga,
no del lenguaje de
implementación. En otras
2 1
palabras, para un sistema de
compensación de seguros escrito
en java, nos preocupamos de la
experiencia del equipo en es
espacio de compensación de
seguros - no cuánto código java
han escrito. Niveles más altos de
0 = sin experiencia, 3=promedio, experiencia
Qué obtienen un
tanta experiencia número
tiene
F2 Experiencia con la más alto.equipo con la aplicación.
5=experto nuestro
Aplicación Esto sólamente será relevante
cuando se trate de
modificaciones a una aplicación
existente. Números más grandes
1
representan más experiencia.
Para una aplicación nueva, la
experiencia de todos será 0.

F3 Experiencia en 0 = sin experiencia, 3=promedio, Cuánta experiencia tiene nuestro

Orientación a Objetos 5=experto equipo en OO? Puede ser fácil
olvidar que muchas personas no
cuentan con experiencia en
programación oritentada a
objetos cuando uno está
1 1 acostumbrado a tenerla. Un
proyecto centrado en el usuario o
centrado en casos de uso tendrá
una estructura inherentemente
OO en su implementación.
Números más grandes
representan mayor experiencia
F4 Capacidad de Análisis 0 = sin experiencia, 3=promedio, en OO.
Qué tan conocedora y capaz es
5=experto la persona responsable de los
del Líder de requerimientos? Los
Requerimientos requerimientos mal especificados
son el factor número uno del
1 fracaso en los proyectos - El
Grupo Standish reporta que del
40% al 60% de los defectos
vienen de requerimientos mal
especificados. Números más
altos representan mayores
F5 Motivación 0=sin motivación, 3=promedio, habilidades
Qué y conocimiento.
tan motivado está nuestro
5=alta 1 1 equipo? Números más grandes
representan mayor motivación.
F6 Requerimientos 0=extremadamente inestable, Los cambios en los
5=sin cambios requerimientos pueden acarrear
estables incrementos de trabajo. La
manera de evitar esto es planear
para el cambio e incluir tiempo
en el cronograma para manejar
2 1
esos cambios. La mayoría de
personas no hace esto, y será
inevitable hacer algo de
retrabajo. Números más grandes
representan mayor cantidad de
cambios previstos (o un sistema
F7 Desarrolladores con 0=ninguno trabaja a tiempo menos efectivo
Nótese para manejarpara
bien, el multiplicador los
parcial , 5=todos trabajan a cambios).
este número es negativo.
dedicación parcial tiempo parcial Números más altos reflejan
miembros del equipo que tienen
dedicación parcial, tal como
-1 desarrolladores que están
dividiendo su tiempo entre
múltiples proyectos. Los cambios
de contexto y otros factores
intangibles hacen que estos
miembros del equipo sean
F8 Dificultad del lenguaje 0=lenguaje fácil, menos
Este eficientes. también es
multiplicador
3=promedio,5=difícil negativo. Los lenguajes más
de programación difíciles representan números
mayores. Consideramos la
-1 dificultad según el punto de vista
del que va a escribir el código
(Java podría ser difícil para un
programador de PL/SQL).
Pensemos en términos de la
dificultad para nuestro equipo.
Factores Ambientales 6
EFactor 1

Puntos de Casos de Uso

Horas hombre por punto de caso de uso 36

Horas hombre estimadas en el Proyecto

Semanas Hombre Estimadas en el Proyecto