Ejemplo de caso de uso

Considerando lo vital que es la gestión de requisitos y lo populares y útiles que son los casos de uso, nunca esta de más intentar una explicación de la técnica. Así que supongamos a un sistema pequeño que nos sirva de ejemplo: el teléfono de un hogar promedio. En dicho sistema, es de interés realizar llamadas de voz, o en otras palabras, el sistema tiene entre sus objetivos el de permitir al usuario del mismo comunicarse remotamente por medio de conexiones de voz.

Primero hemos de identificar al actor. En este caso es claramente el operador o usuario del teléfono. Tendremos en cuenta siempre que cada actor admite solamente cierto tipo de comunicación, impone sus propios requisitos sobre el sistema y exige una funcionalidad bajo ciertas condiciones. Pero para facilitar las cosas podemos simplemente indicarlo; quizás incluso recurriendo a un formalismo gráfico tomado de UML.

Usuario

Fig. 1 – Ejemplo sencillo de un Actor

Ahora podemos identificar cual es la actividad precisa que queremos expresar en nuestro modelo. Digamos que estamos hablando de las llamadas de voz. Así que decimos:

“El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión”.

El párrafo previo contiene la esencia de la situación de llamar por teléfono. A esta breve descripción le llamamos Caso de Uso por cuanto describe la interacción entre un actor -el usuario- y el sistema -el teléfono- indicando el requisito funcional que se exige al sistema.

Ahora bien, ciertamente es difícil referirse a este caso de uso diciendo cada vez el párrafo completo. Por esto le vamos a poner un nombre y un código de identificación. Digamos que le llamamos llamada de voz y que le colocamos el código CS-0100.

Además es claro que antes de hacer la llamada de voz es necesario que el teléfono este colgado así que podemos pensar en una precondición: el teléfono ha de estar colgado.

Armados con estos datos, podemos construir una tabla que resuma lo que tenemos en nuestro caso de uso:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.

Tabla 1 – Detalle de un sencillo Caso de Uso

Y aún más, podemos construir un atractivo diagrama con el fin de comunicar lo que hemos hecho con los clientes.

Sencillo Modelo de Casos de Uso

Fig. 2 – Sencillo ejemplo de un Modelo de Casos de Uso

Si bien en la representación gráfica no aparecen ni la precondición ni la descripción, si en cambio nos ha permitido indicar que el caso de uso (el ovalo) esta en el alcance del proyecto, al haberlo colocado dentro del rectángulo que define los límites del sistema. Por cierto, a dicho rectángulo lo llamamos sujeto en la especificación de UML.

Si en la revisión con los stakeholders identificamos que el caso de uso CS-0100 (el del ejemplo) merece ser detallado más cuidadosamente, entonces y solo entonces, podemos invertir algo de tiempo en la creación de los flujos de eventos. Observemos aquí, que la línea que une al actor con el caso de uso en el modelo gráfico quiere justamente hacer referencia al flujo de eventos.

Al flujo de eventos lo construimos como una tabla, indicando el número del paso el sujeto que realiza la acción y el paso de información que se hace. En aquellos pasos en que estemos hablando del sistema también vamos a indicar la operación o cálculo que este ha de efectuar con los datos. Por otra parte, el flujo de eventos lo vamos a iniciar, casi sin excepción, con el actor.

Flujo Principal:
Paso 1 – Usuario:
Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Tabla 2 – Flujo principal del Caso de Uso

Claro que no siempre las llamadas de voz se corresponden con este flujo de eventos. Sin embargo en un día feliz, cuando todo sale sin problemas, es de esta manera en que sucede. A lo que ocurre en todos los demás casos los vamos a tratar por medio de los flujos alternativos.

Los flujos alternativos pueden ser vistos como una forma de manejo de errores o bien, como un medio para especificar el comportamiento del sistema en caso de un error. Siendo así el caso, una forma de indicarlo es decir una aserción sobre un paso y la acción a tomar cuando esta se viola. Entre las posibles acciones podríamos tener: terminar el caso de uso, saltar a otro paso, presentar un reporte y continuar, etc.

Digamos entonces para efectos del ejemplo, que queremos especificar el comportamiento del sistema cuando el operador a indicado un número inexistente. El siguiente flujo alternativo trata esa situación:

Flujo alternativo: Número incorrecto
Paso 3 – El sistema:
Presenta tono de error y el caso de uso termina.

Tabla 3 – Flujo alternativo del Caso de Uso

Aceptando que claramente es posible indicar tantos flujos alternativos como sean necesarios, además de especificar post condiciones y requisitos no-funcionales relacionados, tenemos entonces un caso de uso sencillo modelado quizás más completamente que lo que en realidad vale la pena. Pongamos todo junto:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.
Diagrama:

Sencillo Modelo de Casos de Uso

Flujo Principal:
Paso 1 – Usuario:
Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Flujo alternativo: Número incorrecto
Paso 3 – El sistema:
Presenta tono de error y el caso de uso termina.

Tabla 4 - Caso de Uso completo

Un modelo de casos de uso es entonces una especificación de funcionalidad desde el punto de vista de la interacción del sistema con sus actores, apoyada en la representación gráfica para facilidad de comunicación pero constituida principalmente por texto.

De momento es todo. Mucho más se puede decir sobre los casos de uso: características avanzadas como la relación de extensión y la relación de inclusión; pero en casi todos los casos priva que mientras más sencillo mantengamos la especificación mejor, lo sencillo se entiende más, y la especificación de requisitos ha de entenderse bien. Que tan sofisticado lo hagamos no es ni de lejos, tan importante como la claridad.

About these ads

, , , , , ,

  1. #1 por marcelo el 11-08-08 - 3:34 am

    ME sirvio bastante, muchas gracias por publicar

    • #2 por Gacelaa el 29-10-10 - 6:40 pm

      El documento es muy util para poder comprender de manera mas explicativa como es el verdadero proceso de un caso de uso..Felicidades al que lo haya publicado y mil graciaz!!!

  2. #3 por TILSON el 25-08-08 - 7:53 pm

    que buen aporte gracias

  3. #4 por Iván Garcerant el 25-08-08 - 9:08 pm

    Que bueno que guste el ejemplo que puse! ¿Tendrá algún sentido poner ejemplos adicionales? ¿o se entiende bien con solo este pequeño ejemplo?

  4. #5 por Jesús Padilla el 12-09-08 - 12:07 pm

    Hola buen dia!

    El ejemplo es muy bueno, sencillo, claro y comprensible.

    Gracias por tu aportación Iván, me sirve de mucho ahora que comienzo con UML y algunas herramientas de diseño.

    Hasta Luego

  5. #6 por Elizabeth el 16-09-08 - 10:32 pm

    Mejor, imposible!, como principiante me ha resultado muy útil el ejemplo de caso de uso. Lo felicito por su fino humor.

  6. #7 por Paula Piedrahita el 26-09-08 - 12:53 pm

    Existe un programa gratis donde se pueda realizar el modelado de caso de usu y diagrama de clase

  7. #8 por Iván Garcerant el 26-09-08 - 9:22 pm

    ¡Claro que sí Paula! Hay varias opciones, la que más te recomiendo, por ser la que yo mismo utilizo, es StarUML (http://www.staruml.com/) Este programa es el que use para los diagramas de este post así como los de la mayoría del blog. Un punto bueno de StarUML es que no solo podrás hacer el diagrama, sino también los reportes en formato de MS Word con lo que te vas a ahorrar mucho tiempo.

    Las otras opciones no son igual de capaces que StarUML, pero quizás también te resulten útiles. El programa ArgoUML (http://argouml.tigris.org/) y el editor Dia (http://www.gnome.org/projects/dia/) son opciones libres que vale la pena evaluar. Ambas también las he utilizado en algunos gráficos del blog con muy buenos resultados.

    Visual Paradigm (http://www.visual-paradigm.com/) es una herramienta comercial con una versión personal que puedes utilizar en proyectos pequeños. Tiene un amplio rango de funcionalidades y lo recomiendo mucho. Sin embargo no es libre para usarlo comercialmente.

    Ahora que si vamos a hablar de software comercial, la herramienta que me tiene más sorprendido es MagicDraw (http://www.magicdraw.com/) las características que tiene son las más potentes y supera a clásicos como Rational Rose (http://www-01.ibm.com/software/rational/)

    En verdad hay muchas opciones. Si te quieres ahorrar la búsqueda, ve directo a StarUML. No te vas a arrepentir.

  8. #9 por pancho el 29-09-08 - 12:15 pm

    gracias

    emmmmmmmmm
    chao

  9. #10 por wigahluk el 30-09-08 - 4:06 am

    Iván

    Sin duda una introducción muy útil a los casos de uso. Ya había leído tu post, pero no lo había comentado porque no tenía nada que discutirle. Ya que me has invitado a leerlo, aprovecho para contribuir invitando a los interesados en profundizar en el tema de los casos de uso y el modelado con UML dentro de un esquema RUP/UP a leer el libro de Craig Larman “Applying UML and Patterns”. Sin duda un clásico de la literatura de desarrollo de software que viene muy a tono no sólo con este post sino con todo tu blog.

    Un saludo

  10. #11 por Cristopher el 6-10-08 - 3:06 pm

    Hola!! Solo para aportar algo sobre los software para el modelado UML, existe una herramienta (comercial) pero muy poderosa llamada Enterprise Architect, la cual permite hacer diagramaciones como

    - Casos de uso
    - Diagramas de estados
    - Diagramas de Transiciones
    - Diagramas de clases
    - etc,

    Te genera los codigos en el lenguaje que prefieras y ademas, los reportes en formato RTF (el cual puedes abrir en MS Word).

    Ademas de modelados de bases de datos en MySQL, PostgreSQL, SQL Server, etc, con sus diagramas, claro está.

    Aqui la versión de demostración en inglés:

    http://www.sparxsystems.com.ar/download/easetup.exe

    Saludos dsd Tabasco, Mexico.

  11. #12 por esteban el 24-11-08 - 9:23 am

    Yo estoy teniendo muy buena experiencia con BoUML. Recomendable 100%.

    http://bouml.free.fr/

    Es una herramienta libre y bastante completa.

    Sds.

  12. #13 por Hieluki el 14-12-08 - 10:21 pm

    Excelente articulo… Mil felicitaciones. Me ha servido mucho

  13. #14 por yhon el 17-02-09 - 8:09 pm

    su ejemplo esta muy bueno, pero lo unico que les falta es como demostrar un poco mas graficamente el mismo

  14. #15 por Iván Garcerant el 19-02-09 - 5:08 am

    Saludos yhon!

    Debes tomar en cuenta que los casos de uso son principalmente artefactos de texto. Los diagramas de casos de uso son útiles para organizar y presentar la información, pero los requisitos están siempre documentados en las partes de texto, como lo son la descripción breve y los flujos de eventos.

  15. #16 por mho el 8-03-09 - 2:59 pm

    excelente articulo y ejemplo, felicitaciones!!

    desde Chile!

  16. #17 por Luis Ponce el 13-05-09 - 10:06 pm

    Buen ejemplo y es super bueno hacer la diferencia entre caso de uso y diagrama de caso de uso.

  17. #18 por ariadna el 11-08-09 - 5:06 pm

    esta bien. adiosito

  18. #19 por Hectorino el 11-08-09 - 5:07 pm

    Esta cañon.adiosito

  19. #20 por Gleny el 23-01-10 - 12:12 pm

    hola, muy buen dia; queria saber si es cierto que los casos de usos definidos en nuestro DCU son las futuras interfaces a realizar. Es decir, si tengo 10 casos de usos entonces eso me indica que deberia tener 10 interfaces?….

    Esto lo pregunto porque un profesor me lo explico asi, y queria saber que tan acertado o errado fue esta aseveracion….

    Gracias x su contestacion…

    • #21 por Iván Garcerant el 25-01-10 - 12:58 pm

      Saludos.

      No soy experto en diseño de interfaces de usuario, pero entiendo que hay gente que efectivamente desarrolla esta a partir de los casos de uso, tanto así que lo que te asegura tu profesor puede efectivamente ser cierto para estos profesionales.

      Sin embargo, hay de todo en la vida, si sigues mi estilo de trabajo es difícil que llegues a tener diez casos de uso, un modelo así de grande sería en mi opinión, complicado de entender, por lo que de trabajar conmigo, tendríamos que prototipar nuestras interfaces de usuario por medio diferentes.

      En ese sentido, yo sugiero siempre empezar con patrones de diseño conocidos, que se encuentran disponibles en la forma de catálogos incluso para las interfaces de usuario.

      Espero haberte contestado tu duda. Cualquier cosa me dejas un comentario por acá.

      Iván.

  20. #22 por Zendy el 25-01-10 - 8:18 pm

    En un caso como este: se tiene un CU Administrar Cuenta de Usuario (que implica el registro,modificacion y eliminacion de datos), resulta correcto en vez de tener solo uno, desglozarlo en 3 cu, que podrian ser: CU:REGISTRO DE CUENTA DE USUARIO, CU: MODIFICAR CUENTA Y CU: ELIMINAR CUENTA ???…..esta bien decir que son casos distintos???…o son tan especificos para ser considerados como tal???…..que lo mejor es quedarse con el CU generico ADMINISTRAR CUENTA DE USUARIO.

    Agradeceria aclare esas dudas…:).

    • #23 por Iván Garcerant el 26-01-10 - 12:32 pm

      Saludos Zendy.

      Yo me quedaría con el caso de uso general, “Administrar Cuenta de Usuario”, indicando en la descripción breve del caso de uso el hecho que dicha administración implica la creación, modificación y eliminación de las cuentas.

      Hay que insistir que el caso de uso es un artefacto de texto, es decir, es una especificación formada por el nombre, la descripción breve y el flujo de eventos; quedando el diagrama solo en un ultimo lugar. Por esto, debes explorar las posibilidades de expresión que te dan la descripción y el flujo de evento antes de ceder a la tentación de crear nuevos casos de uso solo para indicar un requerimiento que te hayan indicado.

      Espero que te haya podido ayudar.

      Iván.

  21. #24 por Zendy el 26-01-10 - 1:49 pm

    ok….GRACIAS….por su rpta.

    Ahora otra duda, siendo que el caso de uso a tomar seria “Administrar Cuenta Usuario” y este incluye el registro,modificacion y elimiancion de los datos….entonces cual es el flujo normal del caso???…si este incluye 3 opciones…

    Se podria decir que el caso de uso empieza cuando el administrador(actor) va a hacer un registro y que la modificacion es un flujo alternativo???….

    Pero se sabe (x la explicacion previa)…que los flujos alternativos son una descripcion ante posibles errores…y x ello NO se puede considerar a la modificacion de datos como tal…..

    Entonces???…como se puede describir un caso de uso tan generico como “Administrar Cuenta Usuario” si este contiene 3 acciones posibles???….una descripcion no hace referencia a una unica accion a seguir??

    Disculpe tantas interrogantes….y muchas gracias por su rpta…:)

  22. #25 por Brenda Lara el 22-02-10 - 6:01 pm

    La verdad es que tengo una tarea muy perra con
    un maestro que nos da POO y quiere que le desarrolle el
    problema de una maquina expendedora en un
    diagrama de caso de uso y no se como hacerle ayudenme por favor espero su ayuda grasias.

    • #26 por Iván Garcerant el 23-02-10 - 5:07 pm

      Saludos Brenda.

      Hay que preguntarse varias cosas de tu ejemplo. Vamos por parte.

      1.- ¿Quién usa el sistema?
      2.- ¿Qué hace el sistema por sus usuarios?

      Esto lo respondemos de la mano de la visión o discusión preliminar que hayamos tenido sobre el sistema. Si nos imaginamos una maquina expendedora, podemos responder de la siguiente forma:

      1.- ¿Quién? El comprador.
      2.- ¿Qué? Vender un producto.

      Esto es una decisión que hemos tomado. Ya que podríamos haber tomado en cuenta también al técnico que llena de productos… según el punto de vista que tengas él también seria un actor.

      Si nos quedamos con el comprador y la función de vender el producto, podemos hacer un caso de uso llamado “Comprar un producto (CS-0100)” asociado al actor “Comprador”.

      La descripción breve seria algo así como: “El comprador inserta las monedas por la cantidad requerida y escoje el producto que desea. La maquina le ha de dar el producto escogido o devolver el dinero en caso de error, ya sea que no haya existencia del producto o que el dinero no haya sido suficiente”

      Podemos derivar de aquí un diagrama de caso de uso muy sencillo, con un actor y un caso de uso, todo muy sencillito y acompañar esto con un diagrama de secuencia, donde se vean los pasos dados por el actor y el sistema durante la ejecución del caso de uso.

      Incluso podrías hacer un pequeño modelo de análisis, con las clases que encuentres relevantes, como maquina, lector de monedas, producto, etc. Si lo haces así, estas clases son de donde vas a tomar las instancias que interactuan en el diagrama de secuencia.

      En este punto tendrías la especificación del problema y su respectivo análisis. Lo compruebas con tu cliente (el profesor en tu caso) y escuchas sus comentarios. En base a esto, iteras y obtienes una segunda versión mejor ajustada a las expectativas y necesidades del cliente.

      Cualquier cosa, puedes volver a preguntar. Y si sacas buena nota, no dejes de avisar. :-)

      Iván.

    • #27 por kiltrus el 24-11-11 - 11:52 am

      je je el ejemplo de la maquina expendedora esta en el libro “aprendiendo UML en 24 horas”.. sorry por la tardanza ;)

  23. #28 por niko santamaria el 20-05-10 - 1:33 pm

    Muy bueno el blog,
    Si se quisiera en este ejemplo poner al receptor, es decir al que recibe la llamada como se haria? y si antes de recibir la llamada esta pasa por un fitro donde existen dos opciones de dejar pasar la llamada o no?

    Muchas gracias

    • #29 por Iván Garcerant el 22-05-10 - 11:04 pm

      Recibir la llamada es un caso de uso diferente. Se ha de ver como la interacción de ese usuario con el sistema, respondiendo el teléfono y encontrándose con una línea de comunicación ya establecida con la otra persona.

      Es decir, tendría un caso de uso “Hacer llamada” con un Actor, y un segundo caso de uso “Recibir llamada”. Curiosamente desde el punto de vista del modelado, este segundo caso de uso tendría el mismo actor del primero.

      Ahora, que si en medio de la comunicación hay otros actores, por ejemplo, una recepcionista, entonces se define el caso de uso correspondiente, independientes de los casos de uso de hacer y recibir llamadas.

      Esta independencia entre los casos de uso puede parecer sorprendente, pero hay que tener en cuenta que el modelo de casos de uso representa los requisitos del sistema, no el flujo de datos o la relaciones lógicas entre las partes.

      Resolver la dependencia que hay entre las distintas actividades que se realizan con el sistema es un asunto del análisis y el diseño de la solución, no una materia de quien levanta los requisitos.

  24. #30 por Pamela Proust el 25-07-10 - 1:03 am

    Muchas gracias Iván, me gustó mucho tu artículo. Me has sacado de un problema de especificación de requisitos que recién tenía. La verdad se aclaran mucho conceptos de los cuales tenía duda. Por favor no dejes de escribir artículos ampliando un poquito más la información acerca de UML y esas cosas.

    Saludos!! ;)

  25. #31 por Fernando el 27-07-10 - 11:01 am

    Hola Ivan,

    Tengo algunas dudas:
    Caso de uso.- viene hacer el flujo de eventos textualmente?
    Diagrama de caso de uso es el gráfico?
    y la especificación de caso de uso, vendría hacer valga la redundancia una especificación detallada, que seria entregada al programador para que el desarrolle?? tendrás ejemplos de este tipo de especificación de caso de uso.

    • #32 por Iván Garcerant el 27-07-10 - 1:50 pm

      Saludos Fernando.

      Un caso de uso es “un escenario de interacción entre el sistema y un ente externo, al que llamamos Actor.” Dicho escenario lo podemos explicar por medio de la descripción breve, de un nombre hábilmente escogido, de un ID único, y como no, por medio de precondiciones, flujos de pasos o eventos y cualquier otro medio que escojamos.

      Es decir, llamamos “caso de uso” a lo que pretendemos describir, y realizamos dicha descripción por diversos medios, entre otros, los flujos de eventos o los diagramas (gráficos) de UML.

      Según que metodología de desarrollo sigas, puede ser que primero hagas un esbozo simple de un caso de uso, quizás solo con diagrama, nombre y ID; y que luego, cuando los detalles pasan a ser necesarios, que desarrolles una especificación que incluya la descripción breve y los flujos. En este sentido, llamaríamos “especificación” a la segunda versión, no por ser algo distinta, sino por tener más detalles “especificados”.

      En el caso de este ejemplo, dado que lo llevamos hasta indicar todos los detalles, podríamos decir que corresponde a una especificación razonablemente completa.

      Espero me haya podido dar a entender. Cualquier cosa no dudes en volver a preguntar.
      Iván.

  26. #33 por Mathesis el 10-08-10 - 11:57 am

    Gracias por publicar este ejemplo y felicitaciones esta muy entendieble.

  27. #34 por Miguel Angel el 11-08-10 - 11:17 am

    Me gustaría que se pusieran ejemplos un poco más complejos. Por ejemplo, cuando el requerimiento hace dificil la identificación de actores, como la creación de interfases, modificaciones a sistemas y funcionalidades ya existentes entre otros.

  28. #35 por Oscar Florez el 4-09-10 - 7:53 am

    Muy entendible el ejemplo gracias.

  29. #36 por Betty castro el 13-10-10 - 11:23 am

    buen día.

    felicitaciones por el bloc, esta muy atendible, en lo personal tenias ciertas dudas referente a los casos de uso y con este bloc se despejaron las dudas

    gracias

  30. #37 por Betty castro el 13-10-10 - 11:25 am

    ojala sigas publicando este tipo de información y utilices el mismo tipo de metodología para ensenar

  31. #38 por cesc1989 el 21-10-10 - 7:28 pm

    Muy buen articulo, explicado de una manera clara y sencilla, Gracias!

  32. #39 por Edgar Hernández el 11-02-11 - 10:13 am

    Excelente artuculo… Muy bien elaborado y explica mejor que muchos prefesores :D

  33. #40 por Leidy Diana Ariza el 30-03-11 - 1:24 pm

    Hola, Ivan he estado leyendo la pagina y me parece interesante lo que escriben y las explicaciones que dan por eso me atrevi a escribir, estoy realizando mi proyecto de grado el cual consiste en la elaboracion de un juego educativo para apoyo en la asignatura de geometria, estuve leyendo u n libro de casos de usos y saque mi “supuesto modelado “, instale StarUml y estoy trabajando en el lo que no entiendo es qcomo pasar lo que ice en papel al sistema, no se si tenga de desglosarlo mas en fin estoy enredada con eso, puedes enviarte tu correo, hay la posibilidad de enviarte mi “pequeño analisis” y tu me dices si lo tengo bien o mal por fisss necesito ayuda

  34. #42 por luiz el 3-04-11 - 6:16 pm

    necesito un diagrama de flujo de venta de billetes en un tren
    me urge

  35. #43 por luiz el 3-04-11 - 6:18 pm

    necesito un diagrama de casos de uso de venta de billetes en un tren
    me urge

  36. #44 por JONATHAN el 13-05-11 - 10:16 pm

    JODER !!! me ha servido de maravilla brother, THANKS

  37. #45 por diana el 6-10-11 - 7:04 pm

    good!!!

  38. #46 por diana el 6-10-11 - 7:06 pm

    Oye por que no poenes ejemplo de un llenado de la plantilla de especificacion de requerimientos m seria muy util por favor !!

    Gracias, Saludos!!

  39. #47 por leandro el 27-11-11 - 12:11 pm

    people como hago un caso de uso Gestionar Reportes? Por favor respondanme lo antes posible

  40. #48 por marcela bustamante el 17-04-12 - 4:19 pm

    Muy buen aporte muchas gracias.

  1. Modelado de Casos de Uso « Tecnología y Synergix
  2. Definimos Caso de Uso como… « Tecnología y Synergix
  3. Los números de 2010 « Tecnología y Synergix
  4. Aqui les dejo un sencillo ejemplo de los casos de uso..!! | mayerlincon

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: