- Puntos de caso de uso
-
Puntos de caso de uso
Es un método de estimación de esfuerzo de un proyecto de desarrollo de software a partir de los casos de uso.
Fue introducido por Gustav Karner en su tesis en 1993 (Universidad de Linkoping) y supervisado por Ivar Jacobson en Objectory AB. Ha sido analizado posteriormente en otros estudios, como la tesis de Kirsten Ribu (Universidad de Oslo) en 2001.
El método utiliza los actores y casos de uso identificados para calcular el esfuerzo que costará desarrollarlos. A los casos de uso se les asigna una complejidad basada en transacciones, que son pares de pasos acción-usuario->respuesta-sistema de los escenarios de los casos de uso. A los actores se les asigna una complejidad basada en el tipo de actor, es decir, si son interfaces con usuarios o si son interfaces con otros sistemas (api o protocolo). También se utilizan factores de entorno y de complejidad técnica para afinar el resultado.
Una vez asignada complejidad a actores y casos de uso y establecidos los factores técnicos y de entorno, se calculan los puntos de caso de uso no ajustados o UUCP, el TCF (factor de complejidad técnica) y el EF (factor del entorno). Con ellos, se calculan los puntos de caso de uso o UCP, que finalmente se traducen a esfuerzo en horas-hombre con un sencillo cálculo.
INTRODUCCIÓN
La planificación es una actividad de gran importancia en el desarrollo de software, al establecerse los objetivos y metas del sistema por desarrollar, a la vez que ayuda a valorar sus costos.
Para que la planificación se logre efectuar de una forma eficiente, resulta fundamental evaluar el sistema de software por desarrollar, con el fin de estimar su nivel de dificultad, buscando obtener un aproximado del tiempo que será requerido en el desarrollo del mismo.
Además, permite determinar el esfuerzo o bien la cantidad de personas necesarias, para lograr finalizar dicho proyecto en un tiempo establecido.
En el presente documento se explicará el proceso para evaluar el tiempo que puede durar un proyecto en su etapa de desarrollo mediante la técnica de puntos de función de casos de uso, donde se explicará cada parte de esta técnica, exponiendo qué es y cómo se debe realizar, además de un ejemplo para facilitar su comprensión.
Seguido de un apartado de conclusiones y recomendaciones.
PROPÓSITO
El propósito de este documento es explicar la técnica de estimación de tiempos llamada “puntos de función de casos de uso” de una manera clara y concisa. Con el fin que esta sea comprendida de la mejor manera posible, así como de cada uno de sus pasos a seguir.
Se procura que sea lo más entendible, por lo que se muestra un ejemplo de cómo se utiliza y de cada uno de los pasos, así como su explicación respectiva.
Se pretende también que se entienda su utilidad en el desarrollo de software, y como esto afecta para bien esta actividad.
TÉCNICAS DE ESTIMACIÓN DE SOFTWARE
Para evaluar la complejidad de un sistema de software existen varias técnicas como son: el método de puntos de función, método COCOMO, punto de casos de uso y model driven architecture. Los cuales han surgido por la misma necesidad, minimizar el impacto de la denominada “crisis del software”, provocada por la complejidad de este proceso, tanto en el desarrollo propio de los sistemas como en la gestión de los mismos. Dicho en otras palabras, estimar lo que costará desarrollar un producto de software.
En las últimas décadas se han desarrollado y perfeccionado estas técnicas para la estimación de proyectos de software, pero bajo el paradigma estructurado y con ciclos de vida clásico, por lo que resulta difícil utilizarlas dentro del paradigma orientado a objetos y/o ciclos de vida iterativo-incrementales.
En este documento se desarrollará el método llamado Punto De Casos De Uso, el cual fue ideado por Gustav Karner, de Rational Software Corporation, en 1993, que estima las “horas-persona” del tiempo de desarrollo de un proyecto, mediante la asignación de pesos a los factores que lo afectan.
TÉCNICA DE PUNTOS DE FUNCIÓN
La técnica de puntos de función, presentada por J. Albrecht a finales de los años 70, pretende estimar el software evaluando la funcionalidad que este proporciona externamente, midiendo lo que el usuario pide y lo que recibe. Proporcionando un factor para la comparación de distintos productos de software, independientemente de la tecnología utilizada para su implementación.
Este análisis se desarrolla considerando cinco medidas básicas, externas del sistema:
- Entradas
- Salidas
- Consultas
- Ficheros Lógicos
- Internos (archivos)
- Externos (interfaces)
Cada una de estas transacciones o ficheros lógicos, debe ser clasificados con una complejidad ya sea Simple, Media o Compleja.
Con estos datos, se determinan los puntos de función sin ajustar.
Con estos puntos de función obtenidos, calculamos los costos del software por desarrollar, con base a una serie de valoraciones relativas a las características generales del sistema y su contexto
Pero esta técnica no está enfocada al paradigma de la orientación a objetos, ni a los ciclos de vida iterativos-incrementales, por lo que se complementó con los casos de uso. De aquí se deriva lo que ahora se conoce como puntos de función de casos de uso, lo cual será explicado en el presente documento.
A continuación se explicará el proceso con más detalle y de una forma más gráfica.
PUNTOS DE FUNCIÓN DE CASOS DE USO
Los casos de uso por sí mismos no permiten efectuar una estimación del tamaño que tendrá el sistema, ni del esfuerzo y el tiempo necesario para implementarlo. Estos permiten documentar los requerimientos del software de una manera compacta y precisa, luego con los puntos de función se puede estimar el tamaño del software a partir de los requerimientos obtenidos de los casos de uso.
Puntos de función de casos de uso consiste en evaluar la complejidad de un sistema de software por medio de una técnica en la que se le asigna una cantidad de puntos de peso, que califican diferentes elementos que componen el sistema de software así como algunos factores del entorno, para obtener una aproximación del tiempo requerido y la cantidad de esfuerzo necesario para la implementación del mismo.
Este proceso se lleva a cabo mediante una serie pasos que como se mencionó anteriormente evalúan cada factor, empezando por ponderar los casos de uso sin ajustar. Esto quiere decir que únicamente son tomados en cuenta los actores (UAW) y los casos de uso (UUCW). Dicho paso se lleva a cabo dejando por el momento los factores técnicos (TCF) y los factores ambientales (EF), para evaluarlos mas tarde. Con el fin de multiplicarlos por el resultado final de los casos de uso sin ajustar. Así, se da el resultado de los casos de uso ajustados, que caracteriza la complejidad del sistema y es usado para obtener una idea del número de horas-persona para un proyecto.
CASOS DE USO SIN AJUSTAR (UUCP)
Al inicio de un proyecto de software, cuando apenas se conocen los casos de uso y sus actores asociados, se puede proyectar una breve descripción de cada caso de uso, en el cual se describe de forma breve la funcionalidad que éste debe brindar.
El UUCP son los puntos de casos de uso sin ajustar, esto nos puede servir para tener una idea un poco más precisa de la dificultad de los casos de uso e interfaces, tomando en cuenta los pesos de los actores (UAW) y los pesos de los casos de uso (UUCW). UUCP = UAW + UUCW
Estas siglas significan:
- 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.
Aplicando el análisis de puntos de función a estos casos de uso, se puede obtener una estimación trivial del tamaño y a partir de ella una estimación del esfuerzo.
FACTOR DE PESO DE LOS ACTORES SIN AJUSTAR (UAW)
Consiste en la evaluación de la complejidad de los actores con los que tendrá que interactuar el sistema. Este puntaje se calcula determinando si cada actor es una persona u otro sistema, además evalúa la forma en la que este interactúa con el caso de uso, y la cantidad de actores de cada tipo.
Tipo de actor Descripción Factor Simple Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API). 1 Medio Otro sistema interactuando a través de un protocolo (ej. TCP/IP) o una persona interactuando a través de una interfaz en modo texto. 2 Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica (GUI). 3 Tabla 1: Peso de los actores sin ajustar.
La fórmula sería: UAW = Sum(cantidadDeUnTipoDeActor*Factor)
Para realizar esta operación sería necesario contar cuántos actores de cada tipo existen en el sistema, este representaría el valor cantidadDeUnTipoDeActor en la fórmula y se tiene que multiplicar por el valor que tenga su factor correspondiente, para obtener el resultado por cada tipo de actor. Una vez terminado esto se procede a sumar cada producto para obtener el UAW.
FACTOR DE PESO DE LOS CASOS DE USO SIN AJUSTAR (UUCW)
Este punto funciona muy similar al anterior, pero para determinar el nivel de complejidad se puede realizar mediante dos métodos: basado en transacciones o basado en clases de análisis.
Una transacción es un conjunto de actividades atómicas, lo que quiere decir que se ejecutan todas o no se ejecuta ninguna.
• Basado en transacciones: Toma en cuenta el número de transacciones que se pueden realizar en un caso de uso y lo evalúa según la siguiente tabla:
Tipo de caso de uso Descripción Factor Simple 3 transacciones o menos 5 Medio 4 a 7 transacciones 10 Complejo Más de 7 transacciones 15 Tabla 2: Peso de las transacciones.
• Basado en clases de análisis.
Toma en cuenta el número de clases que tiene un caso de uso y lo evalúa según la siguiente tabla:
Tipo de caso de uso Descripción Factor Simple Menos de 5 clases 5 Medio 5 a 10 clases 10 Complejo Más de 10 clases 15 Tabla 3: Peso de las clases de análisis.
Ahora independientemente del camino utilizado para determinar el tipo de caso de uso, la fórmula es la misma y se presenta a continuación: La fórmula sería: UUCW = Sum (CantidadDeUnTipoDeCasoUso*Factor) Para realizar esta operación se debe contar cuántos casos de uso de cada tipo hay en el sistema y esta cantidad se sustituiría en el campo nombrado como CantidadDeUnTipoDeCasoUso y se multiplica por el valor que tenga su factor correspondiente, para obtener el resultado por cada tipo de caso de uso. Una vez hecho esto se suma cada producto para obtener el factor de peso de los casos de uso sin ajustar (UUCW).
Esta estimación es bastante imprecisa debido principalmente a la escasa información que se tiene, pero permitirá obtener una idea del esfuerzo necesario para llevar adelante el mismo, y podrá ser refinada a medida que se obtenga más información.
CÁLCULO DE PUNTOS DE CASOS DE USO AJUSTADOS (UCP)
Para esto se utilizan las siglas UCP y se obtiene al multiplicar el UUCP el TCF y el EF quedando la operación de la siguiente forma:
UCP = UUCP x TCF x EF
Estas siglas significan:
- UCP: Puntos de casos de uso ajustados.
- UUCP: Puntos de casos de uso sin ajustar.
- TCF: Factores técnicos.
- EF: Factores ambientales.
EVALUAR LOS FACTORES DE COMPLEJIDAD TÉCNICA (TCF)
Este se compone de 13 puntos que evalúan la complejidad de los módulos del sistema que se desarrolla, cada uno de estos factores tienen un peso definido con los cuales se obtendrá puntos ponderados por cada uno de ellos, según la valoración que se le asigne. Para una mejor comprensión, a continuación se mostrará una tabla con los ítems:
Factor Descripción Peso T1 Sistema distribuido. 2 T2 Objetivos de performance o tiempo de respuesta. 1 T3 Eficiencia del usuario final. 1 T4 Procesamiento interno complejo. 1 T5 El código debe ser reutilizable. 1 T6 Facilidad de instalación. 0.5 T7 Facilidad de uso. 0.5 T8 Portabilidad. 2 T9 Facilidad de cambio. 1 T10 Concurrencia. 1 T11 Incluye objetivos especiales de seguridad. 1 T12 Provee acceso directo a terceras partes. 1 T13 Se requiere facilidades especiales de entrenamiento a usuario. 1 Tabla 4: Peso de los factores de complejidad técnica.
Cada uno de estos puntos se debe evaluar según la siguiente escala:Descripción Valor Irrelevante De 0 a 2. Medio De 3 a 4. Esencial 5 Tabla 5: Escala de los factores de complejidad técnica.
Las fórmulas para este punto son:
- TFactor = Sum (Valor*Peso)
- TCF = 0.6 + (0.01 * TFactor)
Para realizar este cálculo, se debe evaluar cada factor, asignándole un valor como se menciona anteriormente, después se multiplican y se suma cada producto para obtener el TFactor. Luego, se debe seguir la segunda fórmula multiplicando el TFactor por 0.01 y sumar el resultado a 0.6, esto nos va a dar el TCF.
EVALUAR LOS FACTORES AMBIENTALES (EF)
Los factores sobre los cuales se realiza la evaluación son 8 puntos, que están relacionados con las habilidades y experiencia del grupo de personas involucradas con el desarrollo del proyecto. Estos factores se muestran a continuación:
Factor Descripción Peso E1 Familiaridad con el modelo de proyecto utilizado. 1.5 E2 Experiencia en la aplicación. 0.5 E3 Experiencia en orientación a objetos. 1 E4 Capacidad del analista líder. 0.5 E5 Motivación. 1 E6 Estabilidad de los requerimientos 2 E7 Personal part-time -1 E8 Dificultad del lenguaje de programación -1 Tabla 6: Peso de los factores ambientales.
Cada uno de estos factores se debe calificar con un valor de 0 a 5.
Las fórmulas para este punto son:
- EFactor = Sum(Valor * Peso)
- EF = 1.4 + (-0.03 * EFactor)
Para obtener el EFactor se debe sumar todos los productos obtenidos al multiplicar el peso de cada punto por el valor asignado, después se multiplica por -0.03 y se le suma el 1.4. Así, se obtiene el peso de los factores ambientales (EF).
EL ESFUERZO HORAS-PERSONA (E)
Este cálculo se realiza con el fin de tener una aproximación del esfuerzo, pensando solo en el desarrollo según las funcionalidades de los casos de uso. Anteriormente, se sugería utilizar 20 horas persona por UCP, pero a través del tiempo se ha ido mejorando. Está basado en los factores ambientales y se calcula de la siguiente manera:
Primero se debe contar la cantidad de factores ambientales del E1 al E6 que tienen una puntuación menor a 3, también contar la cantidad de estos mismos del E7 y E8 que son mayores que 3.
Factor Filtro De E1 a E6 Factor < 3 De E7 a E8 Factor > 3 Tabla 7: Factor de el esfuerzo horas-persona.
Para evaluar el resultado o la cantidad total según la siguiente tabla:
Horas-Persona (CF) Descripción 20 Si el valor es<=2 28 Si el valor es<=4 36 Si el valor es>=5 Tabla 8: Cantidad de horas-persona según el valor.
El esfuerzo en horas-persona viene dado por:
E = UCP x CF
Estas siglas significan:
E: Esfuerzo estimado en horas-persona.
UCP: Puntos de Casos de Uso ajustados.
CF: Horas-Persona.
Al realizar la multiplicación del UCP por las horas- persona, se consigue un esfuerzo estimado, que representa una parte del total del esfuerzo de todo el proyecto, generalmente un 40%. Este 40% se refiere al esfuerzo total para el desarrollo de la funcionalidades especificadas en los Casos de Uso.
En la siguiente tabla se detallan la distribución en porcentaje, para el esfuerzo total en el desarrollo del proyecto:
Actividad Porcentaje Análisis 10% Diseño 20% Programación 40% Pruebas 15% Sobrecarga 15% EJEMPLO DE CASO DE USO EVALUADO
Para el siguiente ejemplo, se analizara él caso de uso “Retirar dinero del Cajero Automático” y se le aplicará cada uno de los factores que se han especificado en los apartados anteriores. El proceso se explica con el fin de lograr una mayor comprensión del tema y de los pasos que se deben seguir para ponerlo en práctica.
CASO DE USO: RETIRAR DINERO DEL CAJERO
Imagen 1 Caso de uso “retirar dinero del cajero”.
Actores: Cliente Propósito: Realizar un retiro de dinero de una cuenta, desde un cajero automático. Visión General: Un cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar un retiro de dinero. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El cliente toma el dinero y se va.CURSO TÍPICO DE EVENTOS
Acción del Cliente Respuesta del Sistema
- Este caso de uso empieza cuando un cliente introduce su tarjeta en el cajero.
- El sistema pide la clave de identificación.
- El cliente introduce la clave.
- El sistema presenta las opciones disponibles.
- El cliente selecciona la operación de Retiro.
- El sistema pide la cantidad a retirar.
- El cliente introduce la cantidad requerida.
- El sistema procesa la petición y, eventualmente, da el dinero solicitado.
- El sistema devuelve la tarjeta y genera un recibo.
- El cliente recoge el dinero, el recibo y la tarjeta. Procede a retirarse.
Tabla 9: Curso típico de eventos del caso de uso “retirar dinero del cajero”.
CASOS DE USO SIN AJUSTAR (UUCP)
A medida que se van completando las especificaciones de los casos de uso, se pueden ir mejorando las estimaciones de los puntos de función.
FACTOR DE PESO DE LOS ACTORES SIN AJUSTAR (UAW)
Para poder establecer la puntuación para este factor, se utilizará la tabla correspondiente para su estimación:
Tipo de actor Descripción Factor Cantidad Simple Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API). 1 0 Medio Otro sistema que interactúa con el sistema a desarrollar mediante un protocolo (ej. TCP/IP) o una interfaz basada en texto. 2 0 Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica (GUI). 3 1 Tabla 10: Factor de peso de los actores sin ajustar.
Al analizar la tabla, se puede constatar que el cliente constituye un actor de tipo complejo, ya que se trata de la persona que hará uso del sistema por medio de una interfaz gráfica. Por tal razón, se le asigna una puntuación de 3, y como se cuenta con un único actor para este caso, se obtendrá:Tipo de Actor Descripción Peso Complejo Una persona (Cliente) que interactúa con el sistema mediante una interfaz gráfica. 3 Tabla 11: Resultado factor de peso de los actores.
Fórmula:
UAW = Sum (CantidadUnTipoDeActor*Factor).
Paso 1: UAW = 1 X 3 = 3
- Como se cuenta con un único tipo de actor no se tiene que hacer la suma.
Respuesta: UAW = 3
FACTOR DE PESO DE LOS CASOS DE USO SIN AJUSTAR (UUCW)
Para poder establecer los puntajes para este factor, se debe analizar las diferentes transacciones que se llevan a cabo durante la ejecución de este caso, donde una transacción se puede definir como un proceso que se efectúa en el sistema con el cual se obtiene un resultado. Según la cantidad, se puede conseguir el cálculo correspondiente al caso de uso analizado.
Tipo de caso de uso Descripción Factor Simple 3 transacciones o menos 5 Medio 4 a 7 transacciones 10 Complejo Más de 7 transacciones 15 Tabla 12: Factor de peso de los casos de uso sin ajustar.
Se puede identificar dos transacciones en el caso de uso “retirar dinero del cajero automático”. La primera, se da en la etapa de ingresar a la aplicación por medio de la clave, y la segunda, cuando el usuario solicita sacar dinero del cajero, con lo cual se puede asignar un peso de 5, lo que equivale a:
Fórmula: UUCW = Sum (CantidadDeUnTipoDeCasoUso*Factor). Paso 1: UUCW = 2 * 5 = 10
- Como no hay más tipos de casos de uso no se tiene que hacer la suma.
Respuesta: UUCW= 10
En este punto se procede a realizar el cálculo de los Puntos de los Casos de Uso sin Ajustar (UUCP):
Fórmula: UUCP = UAW + UUCW. Paso 1: UUCP= 3 + 10 = 13 Respuesta: UUCP= 13
CÁLCULO DE PUNTOS DE CASOS DE USO AJUSTADOS (UCP)
Este valor se ejecuta mediante los siguientes puntos a estudiar:
FACTOR DE COMPLEJIDAD TÉCNICA (TCF)
Se debe considerar cada uno de los ítems de la siguiente tabla y valorar su peso según al análisis realizado al sistema.
Factor Descripción Peso Valor Asignado Comentario T1 Sistema distribuido. 2 5 Si T2 Objetivos de performance o tiempo de respuesta. 1 4 La velocidad puede ser limitada por el equipo provisto por el cliente. T3 Eficiencia del usuario final. 1 3 El usuario del sistema es de amplia variedad. T4 Procesamiento interno complejo. 1 5 Cálculos Complejos. T5 El código debe ser reutilizable. 1 5 Se desea poder modificar las fuentes para añadir más funcionalidad al sistema. T6 Facilidad de instalación. 0.5 3 El cliente se debe ajustar a algunos requerimientos. T7 Facilidad de uso. 0.5 4 Normal T8 Portabilidad. 2 5 Se solicitó. T9 Facilidad de cambio. 1 4 Se requiere un costo moderado de mantenimiento. T10 Concurrencia. 1 5 Habilitada en el sistema. T11 Incluye objetivos especiales de seguridad. 1 5 Alta seguridad T12 Provee acceso directo a terceras partes. 1 0 No posee T13 Se requiere facilidades especiales de entrenamiento a usuario. 1 5 Sistema fácil de usar. Tabla 13: Peso de los factores de complejidad técnica.
Mediante la tabla anterior se obtienen los datos necesarios para realizar la siguiente ecuación:
Fórmula: TFactor = Sum (Valor*Peso)
TCF = 0.6 + (0.01 * TFactor)
PASO 1:
T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 Total suma 10 4 3 5 5 1.5 2 10 4 5 5 0 5 TFactor:60 Tabla 14: Resultado de los factores de complejidad técnica.
PASO 2: TCP= 0.6+0.01*60
PASO 3: TCF= 0.6+0.6
RESULTADO: TCP=1.2
FACTOR DE AMBIENTE (EF)
Este factor corresponde a puntos que estén relacionados con la empresa desarrolladora que va a evaluar su entorno de desarrollo y los conocimientos de su personal. (Este ejemplo se basa en el perfil del estudiante promedio en el curso de Proyecto 3 -BISOFT21-)
Factor Descripción Peso Valor Asignado Comentarios E1 Familiaridad con el modelo de proyecto utilizado. 1.5 3 El grupo está familiarizado con el modelo a utilizar. E2 Experiencia en la aplicación. 0.5 1 No se tiene experiencia en aplicaciones similares. E3 Experiencia en orientación a objetos. 1 4 El grupo tiene experiencia en programación orientada a objetos. E4 Capacidad del analista líder. 0.5 4 Se seleccionó a uno de los integrantes del grupo para ésta tarea. E5 Motivación. 1 5 El grupo está motivado. E6 Estabilidad de los requerimientos 2 3 Se esperan cambios. E7 Personal part-time -1 5 Todo el grupo es part-time. E8 Dificultad del lenguaje de programación -1 4 Se usará lenguaje Java. Tabla 15: Peso de los factores de ambiente.
Con esto se consigue el siguiente valor en el factor de ambiente: Fórmulas: EFactor = Sum (Valor * Peso). 2- EF = 1.4 + (-0.03 * EFactor). PASO 1:
E1 E2 E3 E4 E5 E6 E7 E8 Suma total 4.5 0.5 4 2 5 6 -5 -4 EFactor=13 Tabla 16: Resultado de los factores de ambiente.
PASO 2: EF= 1.4 + (-0.03 * 13).
PASO 3: EF= 1.4 + -0.39. RESULTADO: EF=1.01
Los Puntos de Casos de Uso Ajustados (UCP) resultan:
Fórmula: UCP = UUCP x TCF x EF
Paso 1: UCP= 13*1.2*1.01= 15.8
Respuesta: UCP= 15.8
EL ESFUERZO HORAS-PERSONA (E)
Contando con las estimaciones realizadas anteriormente, se prosigue a realizar este cálculo.
Fórmula:
E=UCP * Cf
Paso 1:
Basándose en la explicación anterior de este apartado, se diseñó la siguiente tabla:
Factor Filtro Cantidad De E1 a E6 Factor < 3 1 De E7 a E8 Factor > 3 2 Tabla 17: Resultado del factor horas-persona.
Total : 3
Paso 2:
Obtener las horas-persona según la cantidad total de la tabla anterior, evaluándola a continuación:
Horas-Persona (CF) Descripción 20 Si el valor es<=2 28 Si el valor es<=4 36 Si el valor es>=5 Tabla 18: Resultado del esfuerzo en horas-persona.
Obteniendo como resultado CF= 28
Paso 3: *Sustituir la fórmula inicial.
E= 15.8 *28= 442.4
Resultado: E= 442.4
Con dicha fórmula se obtiene un total de 442.4 en esfuerzo de horas de trabajo-persona que se debería tener presentes si se desea realizar la implementación de este sistema.
CONCLUSIONES
• Esta técnica tiene la ventaja de que su estimación no se desvía más del 30% de la realidad.
• Este método nos provee de información que en muchos de los casos es básica para la implementación de proyectos en los que no se tiene una idea muy clara de cómo se va a logra el objetivo.
• Este tipo de evaluación es muy fácil de entender y utilizar, solo con tener las plantillas se puede realizar fácil y rápidamente.
• Ayuda a estimar los gastos de la etapa de desarrollo como el recurso humano requerido.
RECOMENDACIONES
• Apelar a una persona que tenga experiencia en análisis de proyectos y conocer el ambiente de trabajo, para que estas pruebas sean lo más acertadas posibles.
• Contar con una base histórica para utilizarlas de referencia a evaluaciones futuras.
• Utilizar la técnica de puntos de casos de uso cuando se trabaje con el paradigma orientado a objetos y con un ciclo de vida iterativo-incremental.
• Se recomienda realizar este tipo de evaluaciones para lograr una mayor precisión sobre los costos y tiempos de un proyecto.
GLOSARIO
Acrónimos
- API: Application Program Interface.
- E: Effort (Esfuerzo Horas-Persona).
- EF: Environment Factor (Factores Ambientales).
- EFactor: Environment Factor.
- GUI: Graphical User Interface.
- TCF: Technical Complexity Factor (Factores Técnicos).
- TCP/IP: Protocol/Internet Protocol.
- TFactor: Technical factor.
- UAW: Unadjusted Actor Weights (Peso De Los Actores Sin Ajustar).
- UCP: Use Case Point (Puntos De Casos De Uso Ajustados).
- UUCP: Unadjusted Use Case Points (Puntos De Casos De Uso Sin Ajustar).
- UUCW: Unadjusted Use Case Weight (Peso De Los Casos De Uso Sin Ajustar).
Terminologías
- Caso de Uso: Técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. Cada caso de uso proporciona 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.
- Transacción: Es una interacción con una estructura de datos compleja, compuesta por varios procesos que se han de aplicar uno después del otro. La transacción debe ser equivalente a una interacción atómica.
- Interacción atómica: Se realiza de una sola vez y que la estructura a medio manipular no sea jamás alcanzable por el resto del sistema hasta que haya finalizado todos sus procesos.
- Java: Lenguaje de programación orientado a objetos desarrollado por Sun Microsystems
- Ciclo de vida iterativo-incremental: Metodología de desarrollo de software.
- Concurrencia: Es la propiedad de los sistemas que permiten que múltiples procesos sean ejecutados al mismo tiempo, y que potencialmente puedan interactuar entre sí.
- Part-time: Un trabajo a tiempo parcial
- Portabilidad: Característica que posee un software para ejecutarse en diferentes plataformas, el código fuente del software es capaz de reutilizarse en vez de crearse un nuevo código cuando el software pasa de una plataforma a otra.
- COCOMO: El Modelo Constructivo de Costes es un modelo de estimación de costes de software que incluye tres submodelos, donde cada uno ofrece un nivel de detalle.
- Model-Driven Architecture: Es un acercamiento al diseño de software, propuesto y patrocinado por el Object Managemente Group. MDA se ha concebido para dar soporte a la ingeniería dirigida a modelos de los sistemas software.
Fuentes consultadas para la realización de la investigación:
Enlaces externos
Categoría: UML
Wikimedia foundation. 2010.
