viernes, 22 de junio de 2012

Revisando: Casos de Uso (22/06/2012)


  • Casos de uso (Video Clase).
  • Trazabilidad en Enterprise Architect (Video).
  • Casos de Uso - Diagramas de Casos de Uso - Universidad de los Andes.
  • Caso De Uso - Descripcion general (Presentacion).
  • Casos de uso UML (Presentacion).
  • Relaciones entre Casos de Uso en el Unified Modeling Language.
  • Estimación del costo del software usando puntuación en casos de uso: clarificar.
  • Puntos de caso de uso.
  • Ejercicios: Diagramas de casos de uso.
  • Cesar Aldana 21 Casos de Uso (Presentacion).
  • Formatos Casos de Uso (Presentacion).
  • Guia No.2 - Diagramas de Caso de Uso (Presentacion).
  • Proyecto:Guía de Estilo para redactar Casos de Uso.
  • PRJS - Especificación de Casos de Uso.
  • Ejemplos Resueltos De Casos De Uso Ensayos y Documentos.



Casos de uso (Video Clase)

Fuente: youtube.com

Clase sobre Casos de Uso y Diagramas de Casos de Uso (UML). Dictada en la Universidad de Los Andes (http://www.ula.ve) en el curso de Ingeniería de Software durante el semestre A2011.

1

2

3

4

5

6

7

8


9

10

11

12


Uploaded by  on Apr 8, 2011



Trazabilidad en Enterprise Architect (Video)

Fuente: youtube.com

1
Clases - Casos de Uso - Modelado
Esquema de trazado en modelos, para este ejemplo la implementación pasa por las clases y los casos de uso.

2
Trazabilidad Requerimientos,UC y Analsis - Modelado
Esquema de trazabilidad que incorpora requerimeintos, casos de uso y entidades de analisis y diseño como clases y componentes.


Uploaded by  on Oct 28, 2008




Casos de Uso - Diagramas de Casos de Uso - Universidad de los Andes - Demián Gutierrez

Fuente: docs.google.com

Abril 2011




Caso De Uso

Fuente: slideshare.net

Descripcion general sobre casos de uso.


Por Arcangel Gale on Dec 02, 2008




Casos de uso UML

Fuente: scribd.com

Presentación de Casos de Uso en UML. Se indican las referencias del material utilizado para crear esta presentación.


Uploaded by dalpasa




Relaciones entre Casos de Uso en el Unified Modeling Language

Fuente:  docs.google.com

Roxana S. Giandin
Claudia F. Pons
LIFIA, Universidad Nacional de La Plata






Estimación del costo del software usando puntuación en casos de uso: clarificar

Fuente: ibm.com


Resumen:  de The Rational Edge: el método de puntos en casos de uso es un modelo útil para estimar el esfuerzo y el costo de los proyectos de desarrollo de software – siempre que se pueda especificar y contar apropiadamente las transacciones de casos de uso. Este artículo explica cómo contar transacciones con fines de estimación usando este modelo (y cómo no hacerlo). This content is part of the The Rational Edge.

Fecha:  15-03-2009
Nivel:  Introductoria
Actividad:  9950 vistas
Comentario:   0 (Ver | Agregar comentario - Ingrese)

Una parte importante de la toma de decisiones al comenzar un nuevo proyecto de desarrollo de software está dada por el costo que éste tendrá. La estimación de estos costos ha preocupado a analistas de sistema, gerentes de proyecto e ingenieros de software durante décadas. El primer obstáculo es clarificar el alcance del proyecto. ¿Qué debería ser capaz de hacer el sistema? La captura de los requisitos funcionales en casos de uso ha ayudado considerablemente a comunicar los requisitos de una forma que sea comprensible a los usuarios y a otros expertos en el campo. Al comienzo del proyecto debe hacerse un modelo de caso de uso que contenga una lista de todos los actores (usuarios o sistemas externos) y casos de uso del sistema, así como sus nombres y una breve descripción de los mismos. Esta información hace más fácil alcanzar un acuerdo sobre el tamaño del sistema al comienzo del proyecto.
El método de puntos en casos de uso, que esbozaremos a continuación, es un método de estimación prometedor que se adapta bien al enfoque de caso de uso para la descripción de los requisitos. En sus bases yace el concepto de transacción de caso de uso, la unidad más pequeña de medición. Lamentablemente, hay muchas suposiciones disidentes sobre el concepto.
En este artículo examinaremos algunas de estas visiones y cómo funcionan en la práctica. Comenzaremos con un bosquejo del método de puntos de caso de uso, seguido de una discusión sobre cuál es la definición de transacción de caso de uso que mejor funciona. También mostraremos cómo están relacionadas con otros conceptos en torno a los casos de uso. Concluiremos con una discusión sobre cómo contar estas transacciones (y cómo no hacerlo).
Puntos en casos de uso
El método de puntos en casos de uso es un enfoque bien documentado para estimar las actividades de desarrollo de software. 1 Sin embargo, ningún método de estimación se debe usar de manera aislada, sino que se lo debe equilibrar con otros métodos. 2 Aquí nos concentramos en los puntos en casos de uso. La Figura 1 presenta sus fundamentos principales. 3 En sus bases yace el modelo de caso de uso, que consiste en actores y casos de uso. El número y el peso de los casos de uso identificados representan el componente más importante para el cálculo de los llamados puntos de caso de uso sin ajustar. El tamaño de un sistema se calcula a partir de los puntos de caso de uso sin ajustar, ajustándolos según el factor de complejidad técnico obtenido tras considerar las propiedades técnicas del sistema.
Una vez que se tiene una estimación del tamaño del sistema, se puede comenzar a pensar en el cálculo del esfuerzo. Es posible hacer esto calculando el factor ambiental (FE) a partir de las calificaciones del equipo y otras influencias ambientales. Un factor ambiental muy importante es la estabilidad de los requisitos. Se deberá también examinar cuántas horas (H) serán necesarias por cada punto en caso de uso. Finalmente, se deberá añadir el esfuerzo suplementario (ES) no tenido en cuenta en el modelo (como horas de gestión del proyecto, pruebas de integración, etc.) para poder completar la estimación del esfuerzo.




Figura 1: Conceptos principales del método de puntos en casos de uso.
El peso de un caso de uso está dado por el número de transacciones de casos de uso diferentes en la interacción entre el actor y el sistema que se ha de crear.
Según el método de puntos en casos de uso, los criterios para asignar peso a un determinado caso son:
  • Caso de uso simple – de 1 a 3 transacciones, peso = 5
  • Caso de uso medio – de 4 a 7 transacciones, peso = 10
  • Caso de uso complejo – más de 7 transacciones, peso = 15
Por consiguiente, las suposiciones sobre la naturaleza de una transacción y la estrategia usada para contar las transacciones influyen notoriamente sobre la estimación.


¿Qué es una transacción de caso de uso?
El concepto de transacción (de caso de uso) ayuda a manejar la variación en longitud y concisión típicas de las descripciones de casos de uso. Las especificaciones de casos de uso pueden escribirse de manera concisa o bien pueden ser bastante pormenorizadas o detalladas, según la plantilla de caso de uso que se utilice, el enfoque que se adopte, el contexto comercial implicado o las preferencias personales del Requirements Specifier. El número de pasos en un flujo de casos de uso, que describe la interacción entre un actor y el sistema, también puede variar ampliamente tanto entre los escenarios como dentro de ellos. Es posible poner a prueba la “igualdad del tamaño” detectando y contando las transacciones de casos de uso que están implicadas en las especificaciones. Si dos especificaciones de casos de uso tienen el mismo número de transacciones únicas, tienen el mismo tamaño.
Una transacción de caso de uso es un “viaje de ida y vuelta”
Ivar Jacobson, inventor del caso de uso, describe una transacción de caso de uso como un “viaje de ida y vuelta” que va desde el usuario hasta el sistema para luego volver al usuario; una transacción está terminada cuando el sistema espera un nuevo estímulo de entrada. 4 En otras palabras, en una transacción el actor lleva a cabo una acción que representa una entrada para el sistema. A continuación, el sistema reacciona, es decir, procesa la entrada y devuelve el resultado al actor. Cuando el actor reacciona ante el resultado comienza una nueva transacción, que a su vez representa una nueva entrada para el sistema.
Una transacción de caso de uso no siempre es un paso de caso de uso
La afirmación de Jacobson implica también que una transacción de caso de uso no es por definición “un paso en el flujo de casos de uso”. Esto sólo es verdadero si un paso en un flujo de casos de uso consiste en sí mismo en un “viaje de ida y vuelta”. Aunque algunos enfoques sobre la escritura de casos de uso recomienden este método alternativo para definir transacciones de casos de uso, no es de modo alguno el método estándar de hacerlo. 5
Una transacción de caso de uso no es un “estímulo” en sí mismo.
Algunos autores sugieren que “la existencia de un estímulo generado por un actor es lo que define una transacción”. 6 Aunque una transacción comience con un estímulo (el actor hace algo que dispara el sistema), el estímulo en sí mismo no es la transacción completa. Supongamos que tenemos una descripción de caso de uso que diga:
El usuario selecciona una X.
...

(n) El usuario envía.
...
Entonces no queda claro si el sistema reacciona a los estímulos de los pasos (1) y (n) en una sola reacción o si, en cambio, el sistema reacciona a los pasos (1) y (n) por separado. Por lo tanto, dos estímulos podrían constituir una transacción o dos. Esto no depende de los estímulos sino de la combinación de estímulo y respuesta.
Una transacción de caso de uso no es una actividad de base de datos
En muchas discusiones en la Web suele encontrarse que la transacción de casos de uso se define como “un conjunto de actividades que se realiza completamente o no se realiza”. 7 Esta definición suena como la de un mecanismo transaccional en un sistema de gestión de bases de datos, en el que puede repetirse un paso si no se realiza correctamente. Según nuestra experiencia, este no es un buen modo de aislar una unidad de contenido de otra en una descripción de casos de uso, ya que puede suscitar la idea de que una transacción está relacionada de alguna manera con una acción de lectura o escritura en una base de datos. Sin embargo, es bastante posible que, en un viaje de ida y vuelta, el sistema no tenga que consultar a la base de datos en absoluto. Incluso puede no haber una base de datos implicada, o inclusive los datos pueden provenir desde afuera del sistema. Por consiguiente, no es apropiado concluir que las transacciones de casos de uso están necesariamente vinculadas a las transacciones en una base de datos.
Una transacción de caso de uso no es un paso del sistema
La respuesta del sistema en una transacción de caso de uso se puede escribir como un paso. En apariencia, uno podría tener la impresión de que una transacción de caso de uso sóloesun paso del sistema. Sin embargo, no es una buena base para definir una transacción de caso de uso, ya que la cantidad de pasos que se cuenten dependerá de la granulación de la descripción del flujo. Además, los pasos de sistema solos no dicen mucho sobre la interacción que ocurre entre un Actor y el sistema. En otras palabras, la estimación debería basarse en transacciones que sean “viajes de ida y vuelta”, y no en pasos del sistema.
Un ejemplo: interfaces complejas de usuario
El enfoque de “viaje de ida y vuelta” para las transacciones de casos de uso muestra su valor en el caso de la estimación de la complejidad de las interfaces de usuario. El ejemplo que seguiremos proviene de un proyecto de portal de trabajo, en el cual se diseñó un motor de búsqueda de trabajo. En la estimación temprana basada en el modelo de casos de uso (Sondeo), la interfaz de búsqueda de trabajo se consideró simple; se esperaba que el usuario seleccionara los ítems de búsqueda de un par de menús desplegables y luego realizara su selección. Sin embargo, en las sesiones de usuario dedicadas a producir la especificación se hizo evidente que la utilidad de la aplicación se vería mejorada si el sistema pudiera responder a selecciones ya hechas, cambiando el contenido de los menús desplegables. En otras palabras, lo que se consideró originalmente una transacción terminó siendo dos.
He aquí el primer borrador de la especificación de caso de uso:

 Este texto se expandió de la manera siguiente:


Aquí puede verse claramente los dos “viajes de ida y vuelta”. Con la especificación de caso de uso como testimonio, se hizo fácil ver la razón fundamental para ajustar la estimación inicial.
Mantener las transacciones de casos de uso en el nivel apropiado.
Si una transacción de caso de uso es un estímulo seguido de una respuesta del sistema, entonces ¿casi todo se consideraría una transacción? Por ejemplo, si escribo el carácter 'R' en mi teclado, éste es un estímulo, y el sistema responde a él produciendo algunos píxeles en la pantalla que son identificables como 'R'. Entonces ¿no es la definición que hemos estado recomendando demasiado limitada?
No, no lo es. Esta objeción muestra que sería necesario interpretar las transacciones de casos de uso al mismo nivel en que se supone que el caso de uso en sí debe ser interpretado. Hoy en día, nadie estaría especialmente interesado en el fenómeno de escribir un carácter y que éste aparezca en algún lugar de la pantalla. Se lo da por descontado, no es necesario crear algo en el sistema para producir este resultado. Sin embargo, si el contexto es una descripción de la interacción entre un módulo de teclado y un procesador gráfico, tal transacción de caso de uso tiene total sentido.


Cómo contar las transacciones
Ahora que tenemos una base clara para determinar qué es y qué no es una transacción de caso de uso, examinemos algunos desafíos de contar las transacciones dentro de los casos de uso. Como se mencionó anteriormente, el peso de un caso de uso está dado por el número de transacciones de casos de uso diferentes que contiene. Pero, ¿exactamente cuándo la reacción del sistema a un estímulo se considera diferente?
Transacciones y flujos de caso de uso
Comencemos examinando el flujo de búsqueda del portal de trabajo presentado anteriormente. Si el actor busca un trabajo en la categoría “Java”, seleccionará Java y el sistema buscará en su base de datos todos los trabajos en dicha categoría. Cuando el actor busque un trabajo en la categoría “.Net”, seleccionará .Net y el sistema buscará en su base de datos todos los trabajos de la categoría antedicha. ¿Son diferentes estas dos transacciones? Claramente no. La especificación de caso de uso en sí es abstracta o genérica, en el sentido en que uno no espera diferentes flujos para diferentes términos de búsqueda. Hay sólo una diferencia en la creación de instancias. Sin embargo, uno esperaría flujos diferentes para, supongamos, una búsqueda que utilice categorías predefinidas o una búsqueda de texto de formato libre.
Por otro lado, el manejo de las excepciones es un área gris. Supongamos que tenemos una pantalla de entrada con siete campos, todos con restricciones diferentes. Tenemos un campo de fecha, otro de código postal, un tercero cuya entrada está condicionada al contenido de otro, etc. Cada comprobación puede describirse en un flujo separado, y por lo tanto puede considerarse al menos una transacción. Como alternativa puede proporcionarse un flujo de excepción genérica. Este presupone que se cuenta con un marco en el cual se pueden manejar fácilmente varios tipos de excepciones. En este caso, debería considerarse el flujo como una transacción.
Las transacciones de casos de uso, al ser viajes de ida y vuelta, se deberían esperar en todas las partes del caso de uso. Dado que una especificación de caso de uso tiene al menos un flujo básico, también tiene al menos una transacción. Un flujo sin transacción no es significativo, ya que de este modo el sistema estaría haciendo algo sin estímulo, o bien el actor proporcionaría uno o varios estímulos sin tener certeza de cuál será la reacción del sistema.
Casi siempre hay flujos que describen el manejo de una excepción (de allí su nombre “flujos de excepción”). Cada flujo de excepción contiene al menos una transacción. Lo mismo es válido para un flujo alternativo; aquí se tiene al menos una transacción por flujo alternativo. Puede darse el caso de que se tenga que examinar el flujo básico para ver el estímulo de la transacción en el flujo alternativo; esto dependerá de las pautas específicas al detallar un caso de uso.
Esto nos da una indicación de la cantidad mínima de transacciones de casos de uso en cualquier especificación de caso de uso: hay al menos tantas transacciones como flujos. 8
Mostrar y (no) contar
Dada la capacidad de identificar las transacciones de casos de uso, ¿es necesario tomar todas y cada una de las transacciones con la misma seriedad? Nuestra estrategia es mostrar todas y cada una de las transacciones (de ser pertinente), pero en ocasiones no tener en cuenta su peso. Esta estrategia es más sencilla de seguir que simplemente ignorar las transacciones si parecen “demasiado livianas”. También es más fácil ajustar la estimación original, de ser necesario.
De esta manera, uno puede mostrar el valor de los marcos. Si un caso de uso cuenta diez transacciones, pero sólo siete de ellas requieren esfuerzo y tres “siguen” a partir del marco, aquel caso de uso es de complejidad media más que complejo. La Tabla 1 muestra un ejemplo.

Tabla 1: Transacciones contadas a través de casos de uso hipotéticos

Caso de usoN de transaccionesN de transacciones contadasMotivoPeso del caso de uso
1 Solicitar trabajo43Simple
2 Encontrar trabajo33Simple
3 Evaluar solicitud107marcoMedio

Muchos pasos del sistema podrían ser un nuevo caso de uso
¿No hay algún modo de justificar la diferencia entre tener muchos pasos del sistema implicados por una transacción de caso de uso frente a tener un sólo paso en el sistema? La intuición sugiere que exige más esfuerzo crear seis pasos en el sistema que uno solo. Estamos completamente de acuerdo. Sin embargo, uno no debería tratar de resolver este pequeño rompecabezas contando pasos del sistema como transacciones, sino aislando la funcionalidad involucrada en estos pasos suplementarios del sistema. Si se tiene un cúmulo evidente de funcionalidad, entonces probablemente sea un caso de uso en sí mismo. Hay que tener cuidado de no llevar cualquier cúmulo de funcionalidad al estado de 'caso de uso' – eso sería descomposición funcional – sino aplicar la regla siguiente: los candidatos a casos de uso siempre deben tener un objetivo claro que se corresponda con el interés de al menos un involucrado (que no es necesariamente equivalente a actor). 9
Un ejemplo podría ser el caso de uso “Generar balance anual”. En el transcurso de este caso de uso se generan varios informes, cada uno de interés para un involucrado específico. Hay varios pasos del sistema implicados en la generación de cada informe. Definir un caso de uso individual para cada informe nos ayuda a encontrar la parte involucrada correcta y a no molestar a otros involucrados. De esta manera, somos capaces de proporcionar una estimación más detallada.
Trabajos por lotes
Si es cierto que un caso de uso también debiera usarse en ausencia la interacción del usuario (y tenemos buenas experiencias haciéndolo), entonces, ¿cómo podemos aplicar el concepto de transacción como viaje de ida y vuelta? Bien, francamente, no se aplica aquí. Se necesitan otras formas de estimar el peso de tales casos de uso. Esto generalmente se hace por estimación de expertos. La Tabla 2 muestra cómo se podría ver esto en la hoja de cálculo.

Tabla 2: Recuento de transacciones con el trabajo por lotes agregados

caso de usoN de transaccionesN de transacciones contadasMotivoPeso del caso de uso
1 Solicitar trabajo43Simple
2 Encontrar trabajo33Simple
3 Evaluar solicitud107marcoMedio
4 leer archivo plano en la base de datos----Estimación de expertoComplejo

Si un trabajo por lotes claramente es mucho más grande que un caso de uso complejo, bien podrá servir a más de un propósito y, en consecuencia, el trabajo debería dividirse en más casos de uso, donde cada uno sirva a su propio objetivo de ser de interés a por lo menos un involucrado. Este es un mecanismo aplicable a cualquier caso de uso que aparente ser considerablemente más complejo de lo que uno generalmente considera “Complejo” (ver Tabla 2). Si no se puede encontrar una buena razón para dividir el trabajo por lotes, se puede volver a la categoría de “esfuerzo suplementario” mencionada en la Figura 1.
Casos de uso muy complejos
Algunos autores encuentran dificultoso el método de puntos en casos de uso porque no hay diferencia alguna entre un caso de uso complejo de, supongamos, ocho transacciones, y un caso de uso complejo de dieciséis transacciones. Según nuestra experiencia, los casos de uso que consisten en más de doce transacciones sirven a más de un propósito. Y, por lo tanto, son un indicio de modelo de caso de uso problemático. En otras palabras, vale la pena considerar un nuevo caso de uso si en algún punto se tiene un caso de uso de más de doce transacciones. 10
Contar transacciones de caso de uso al comienzo del proyecto
Contar transacciones es fácil cuando todas las especificaciones de casos de uso están escritas. Por otra parte, se espera hacer al comienzo del proyecto la estimación. En ese punto, uno sólo tiene el modelo de casos de uso con una breve descripción por caso de uso. Para poder prever los flujos que compondrán los casos de uso y las transacciones de casos de uso que éstos involucren, se necesita experiencia. Si no se cuenta con esta experiencia, no hay que dudar en consultar a colegas que hayan trabajado con sistemas y contextos similares. Se recomienda empezar creando una hoja de cálculo como la que figura en la Tabla 2, y luego rellenar las transacciones previstas. Esto constituirá la base para administrar el alcance de los casos de uso, ya que así uno podrá explicar detalladamente qué casos de uso implican más transacciones que las previstas inicialmente por el cliente.


Conclusión
A fin de aplicar el método de puntos de caso de uso para la estimación del esfuerzo de software, es importante tener una buena idea de su componente básico. Tal componente es el concepto de transacción de caso de uso, y lo mejor es tomar éste como un viaje de ida y vuelta, desde el estímulo iniciado por el actor hasta la respuesta del sistema. La transacción está terminada cuando el sistema espera un nuevo estímulo.
Trabajando con este concepto, hemos hecho algunas sugerencias sobre cómo y cuándo contar transacciones. Si bien esto es más un arte que una ciencia, el hecho de aplicar estas recomendaciones con sentido común y experiencia puede ayudarnos a hacer estimaciones más exactas del costo y el esfuerzo al comienzo del proyecto.


Referencias
[1] Jacobson, Ivar et al., “Object-Oriented Software Engineering. A Use Case Driven Approach”, impresión revisada, Addison-Wesley, 1993.
[2] Cockburn, Alistair, “Writing Effective Use Cases”, Addison-Wesley, 2001.
[3] Ribu, Kirsten, “Estimating Object-Oriented Software Projects with Use Cases”, MSc Thesis, Oslo 2001, descargable en http://heim.ifi.uio.no/%7Ekribu/oppgave.pdf
[4]Övergaard, Gunnar et Karin Palmkvist, “Use Cases: Patterns and Blueprints”. Addison-Wesley, 2005.
[5] Mohagheghi, Parastoo, Bente Anda et Reidar Conradi, “Effort estimation of Use Cases for incremental large-scale software development”,International Conference on Software Engineering (ICSE), 2005, pp. 303-31.
[6] Laird, Linda M. et M. Carol Brennan, “Software Measurement and Estimation: A Practical Approach”. Wiley-Interscience, 2006.
[7] Robiolo, Gabriela et Ricardo Orosco, “Employing Use Cases to early estimate effort with simpler metrics”, Innovations in Systems and Software Engineering, Vol. 4, N 1, 04/2008, pp. 31-43.
[8] Issa, Ayman, Mohammed Odeh et David Coward, “Software Cost Estimation Using Use-Case Models: a Critical Evaluation”, Information and Communication Technologies, 2006. ICTTA '06. 2Vol. 2, pp. 2766-2771.
[9] Vinsen, Kevin, Diane Jamieson et Guy Callender, “Use Case Estimation -- The Devil is in the Detail”, 12th IEEE International Requirements Engineering Conference (RE'04), 2004, pp. 10-15.
[10] Braz, Marcio Rodrigo et Silvia Regina Vergilio, “Software Effort Estimation Based on Use Cases”, Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC '06), 2006, pp. 221-228.
[11] Diev, Sergey, “Use cases modeling and software estimation: Applying Use Case Points”, ACM Software Engineering Notes, Vol. 31, N 6, 11/2006.
[12] Anda, Bente, Endre Angelvik et Kirsten Ribu, “Improving Estimation Practices by Applying Use Case Models”, Profes, 2002, LNCS 2259, pp. 383-397.
[13] Bittner, Kurt et Ian Spence, “Use Caseuse case Modeling”. Pearson Education, 2003.
[14] Kusumoto, Shinji et al., "Estimating Effort by Use Case Points: Method, Tool and Case Study",Proceedings of the 10 th International Symposium on Software Metrics (METRICS'04), 2004.
[15] Koirala, Shivprasad, “How to Prepare Quotation Using Use Case Points”, The Code Project, 12/2004.
[16] Probasco, Leslee, “Dear Dr. Use Case: What About Function Points and Use Cases?”,The Rational Edge, 08/2002.


Notas
  1. Las descripciones detalladas, las hojas de cálculo y las herramientas están disponibles en Internet y en varias publicaciones; por ejemplo: [6], [3], [12].
  2. Ver [6] para una descripción general de los métodos de estimación.
  3. Adaptado de una figura similar que se encuentra en Diev [11].
  4. [1], p. 127; comparar también [2], p. 93-94.
  5. [2], p. 119-127.
  6. [7], p. 35.
  7. [3], p. 20, [14], sección 2.1, [15].
  8. Diev [11] concibe la posibilidad de dos (¿o más?) escenarios de caso de uso en una transacción de caso de uso. Él afirma: “...la transacción de caso de uso 'Compra de producto financiero' puede contener un escenario para una compra exitosa y otro para una compra fallida [sic].” No creemos que ésta sea una buena idea, ya que entonces la relación entre transacciones y escenarios se vuelve confusa. El escenario de “compra exitosa” consiste en al menos un estímulo y una respuesta. El escenario de “compra fallida” consiste en el mismo estímulo que el del escenario de éxito, pero con una respuesta diferente del sistema. Por lo tanto, esto constituye dos transacciones en lugar de una.
  9. Ver [4], p. 36-37.
  10. Robiolo y Orosco intentan resolver el problema de cómo contar casos de uso muy complejos en conjunto. Estos autores no relacionan las transacciones de casos de uso con la complejidad de los casos de uso, sino que simplemente agregan todas las transacciones encontradas en los casos de uso y calculan directamente el tamaño de una aplicación a partir de la cantidad de transacciones [7], p. 35. Esto suena prometedor pero, por lo que sabemos, aún debe hacerse una importante investigación de las reglas aplicables. Por el momento preferimos usar el método de puntos de caso de uso. Además, a fin de mantener la interoperabilidad, no deseamos cambiar su base como se propone a veces; por ejemplo: cambiando la proporción transacción/complejidad ([5], tabla 3); haciéndole agregados (puntos de tamaño de casos de uso, puntos de tamaño de casos de uso confusos [10]); o cambiando las transacciones para “escenarios clave” [16].

Recursos
  • Participar en el foro de debate.
  • Un nuevo foro se ha creado específicamente paraartículos de Rational Edge,por lo tanto usted ahora puede compartir sus ideas sobre éste u otros artículos del número actual o de nuestros archivos. Lea lo que sus colegas de todo el mundo tienen para decir, genere sus propias discusiones o únase a las discusiones en curso. Comience haciendo clic AQUÍ.
  • Global Rational User Group Community
Sobre los autores
Remi-Armand Collaris es Project Manager y Consultor de Rational Unified Process®(RUP®) en Ordina, compañía con sede en los Países Bajos. Ha manejado proyectos de desarrollo de software EE/RUP en Java para varias instituciones financieras y semi-gubernamentales. Una parte importante de su trabajo en Ordina es contribuir al caso de desarrollo de RUP de la compañía y dar presentaciones y talleres sobre RUP, Scrum y gestión de proyectos. Con Eef Dekker como coautor, escribió el libroRUP op Maat: Een praktische handleiding voor IT-projectenen holandés, traducido al inglés comoRUP Tailored: A Practical Guide to IT Projects, segunda edición revisada, publicada en 2008 (ver www.rupopmaat.nl).
Eef Dekker es System Analyst y Consultor de Rational Unified Process®(RUP®) en Ordina, compañía con sede en los Países Bajos. Una parte importante de su trabajo en Ordina es contribuir al caso de desarrollo de RUP de la compañía y dar presentaciones y talleres sobre RUP y Modelado de Casos de Uso. Con Remi-Armand Collaris como coautor, escribió el libroRUP op Maat: Een praktische handleiding voor IT-projectenen holandés, traducido al inglés comoRUP Tailored: A Practical Guide to IT Projects, segunda edición revisada, publicada en 2008 (ver www.rupopmaat.nl).


Remi-Armand Collaris, Project Manager and RUP Consultant, Ordina
Eef Dekker, System Analyst and RUP Consultant, Ordina





Puntos de caso de uso

Fuente: es.wikipedia.org

Puntos de caso de uso
 es un método de estimación de esfuerzo para proyectos de software, a partir de sus casos de uso. Fue desarrollado por Gustav Karner en 1993, basándose en el método de punto de función, y supervisado por Ivar Jacobson. 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 relevados para calcular el esfuerzo que significará desarrollarlos. A los casos de uso se les asigna una complejidad basada en transacciones, entendidas como una interacción entre el usuario y el sistema, mientras que a los actores se les asigna una complejidad basada en su tipo, es decir, si son interfaces con usuarios u otros sistemas. También se utilizan factores de entorno y de complejidad técnica para ajustar el resultado.

Contenido

Método

El método de punto de casos de uso consta de cuatro etapas, en las que se desarrollan los siguientes cálculos:
  1. Factor de peso de los actores sin ajustar (UAW)
  2. Factor de peso de los casos de uso sin ajustar (UUCW)
  3. Puntos de caso de uso ajustados (UCP)
  4. Esfuerzo horas-hombre

Puntos de caso 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 actorDescripciónFactor
SimpleOtro sistema que interactúa con el sistema a desarrollar mediante una interfaz de programación (API).1
MedioOtro 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
ComplejoUna 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 usoDescripciónFactor
Simple3 transacciones o menos5
Medio4 a 7 transacciones10
ComplejoMás de 7 transacciones15
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 usoDescripciónFactor
SimpleMenos de 5 clases5
Medio5 a 10 clases10
ComplejoMás de 10 clases15
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.

Puntos de caso 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.

Factores de complejidad técnica

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:
FactorDescripciónPeso
T1Sistema distribuido.2
T2Objetivos de performance o tiempo de respuesta.1
T3Eficiencia del usuario final.1
T4Procesamiento interno complejo.1
T5El código debe ser reutilizable.1
T6Facilidad de instalación.0.5
T7Facilidad de uso.0.5
T8Portabilidad.2
T9Facilidad de cambio.1
T10Concurrencia.1
T11Incluye objetivos especiales de seguridad.1
T12Provee acceso directo a terceras partes.1
T13Se 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ónValor
IrrelevanteDe 0 a 2.
MedioDe 3 a 4.
Esencial5
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.

Factores ambientales

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:
FactorDescripciónPeso
E1Familiaridad con el modelo de proyecto utilizado.1.5
E2Experiencia en la aplicación.0.5
E3Experiencia en orientación a objetos.1
E4Capacidad del analista líder.0.5
E5Motivación.1
E6Estabilidad de los requerimientos2
E7Personal part-time-1
E8Dificultad 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).

Esfuerzo horas-hombre (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.
FactorFiltro
De E1 a E6Factor < 3
De E7 a E8Factor > 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
20Si el valor es<=2
28Si el valor es<=4
36Si 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:
ActividadPorcentaje
Análisis10%
Diseño20%
Programación40%
Pruebas15%
Sobrecarga15%

Referencias

  • Comparing Effort Estimates Based on Use Case Points with Expert Estimates - Bente Anda

Enlaces externos





Ejercicios: Diagramas de casos de uso

Fuente: docs.google.com





Cesar Aldana 21 Casos de Uso

Fuente: scribd.com


Uploaded by giogle




Formatos Casos de Uso

Fuente: scribd.com


Uploaded by dafelosa




Guia No.2 (Diagramas de Caso de Uso)

Fuente: scribd.com


Uploaded by giogle




Proyecto:Guía de Estilo para redactar Casos de Uso

Fuente: docs.google.com

Autor:Josep Vilalta – jvilalta@vico.org  vico.org 2002




PRJS - Especificación de Casos de Uso

Fuente: docs.google.com

Llenguatges i Sistemes Informàtics Enginyeria del Software: Especificació

Cuatrimestre Otoño 03/04





Ejemplos Resueltos De Casos De Uso Ensayos y Documentos

Fuente: buenastareas.com

No hay comentarios:

Publicar un comentario en la entrada