Avistar
Sabías qué...

Nuestros cursos de Certificación PMP® y CAPM® incluyen 40 y 24 horas respectivamente de capacitación presencial más un programa integral en línea para complementar tu preparación desde la comodidad de tu casa, y garantizar tu certificación.

17 módulos en video (80 videos)
60 contact hours / PDUs
Simulador de examen
Autoevaluaciones por cada video
Acceso al foro No. 1 de PM en español
Libro digital de Pablo Lledó
60 plantillas de PM
PMBOK® Guide con descuento

Entre otros beneficios...

Ver aquí


Información general
Novedades
Conoce la Póliza Abiztar Plus
Nuestros clientes
Recomendaciones de capacitación
Calendario de cursos

Cursos de Ingeniería de software
Bootcamp de UML
Modelado con SysML
Modelado de Negocios /BPMN
Patrones de Diseño
Casos de Uso
TOGAF
Desarrollo automatizado de software con MDA
Grails
Java 6
Fundamentos de Pruebas

Cursos de Dirección de proyectos
Certificación PMI-RMP®
Certificación PMI-SP®
Certificación PMP®
Certificación CAPM®
SCRUM
Estimación de Proyectos
Seguimiento de Proyectos
Simulacro en proyectos de SW
Calendarización con MS Project y PMBOK®

Base de conocimiento
UML y Arquitecturas
Administración de Proyectos
Procesos de Software
Artículos

Los Casos de Uso y el Valor del Sistema

Por Sergio Orozco.

A quién no le ha pasado que siente la necesidad de comprar algo sólo para terminar con ese producto en un rincón sin jamás ser utilizado. Nos pudo haber pasado porque no alcanzó nuestras expectativas, o porque resultó demasiado complicado de utilizar, o porque en realidad no era una verdadera necesidad sino simplemente un capricho. Sea cual fuera la razón, la realidad es que hicimos un gasto inútil e innecesario.
Con el software, y en particular con el desarrollo de software a la medida ocurre con bastante frecuencia algo similar. Pues, no es raro encontrarse con empresas que contratan un desarrollo de software sólo para darse cuenta de que desperdiciaron su dinero y su tiempo, pues no obtuvieron lo que ellos esperaban o necesitaban. En otras palabras, no obtuvieron el valor que esperaban recibir para su negocio con el software adquirido.

La Administración de Requerimientos

Una de las razones principales por las cuales se da esta situación, y de hecho, una de las causas principales por las cuales los proyectos de desarrollo fracasan o por lo menos no tienen el éxito que deberían, se debe a una mala administración de requerimientos. Esto generalmente se da por falta ya sea de habilidades en el personal responsable o de técnicas apropiadas utilizadas para llevar a cabo esta labor.

La administración de requerimientos, de acuerdo a CMM, abarca actividades como la recopilación, documentación, validación y control de los requerimientos y sus cambios. UML, como estándar integrador de las buenas prácticas de desarrollo nos ofrece en este sentido los casos de uso como una técnica excelente para administrar los requerimientos de nuestros proyectos.

¿Consultoría o Manufactura?

Si queremos realizar una verdadera consultoría de software entonces nos corresponde algo más que escuchar la lista de funciones que el cliente cree que debería de tener su sistema (a menos que nuestro cliente tenga un área con la capacidad de realizar una buena recopilación y análisis de requerimientos).
Si nos limitáramos a lo primero entonces en lugar de llamarle consultoría a nuestro trabajo, deberíamos llamarle manufactura de software, donde uno implementa las funciones exactamente como se las solicita el cliente, cuestionando nada o muy poco, tal como se haría en una planta manufacturera donde se reciben las especificaciones del producto a construir.

El Sistema y su Misión

Si queremos desarrollar el mejor sistema posible debemos realizar un trabajo serio para identificar, en primer lugar, cuál es el valor que el sistema debe proporcionar al negocio. Para lo cual habrá que preguntárselo a las personas que obtendrán alguna clase de beneficio cuando se ponga en operación. Una buena parte de estas personas probablemente vayan a ser usuarios del sistema; en UML los conocemos como Actores (más adelante veremos otros tipos de Actores que también tendremos que identificar).

Buscando los Beneficios del Sistema

Una vez identificados los usuarios del sistema (actores primarios) habrá que preguntarles en qué situaciones valdrá la pena para ellos utilizarlo. La lista identificada de dichas situaciones no debería de tener pequeñas funciones, sino flujos completos que le proporcionen suficiente valor tanto a ellos como al negocio, de manera que “valga la pena usar el sistema” en dichas situaciones.
Ejemplo: un vendedor en cierto sistema de ventas querrá “Registrar venta”, “Registrar pedido”, “Consultar comisiones”, “Administrar prospectos”, “Generar factura” y “Administrar clientes”. Todas ellas son ejemplos de situaciones u objetivos importante que podría necesitar un vendedor para llevar a cabo su trabajo, conocidas y modeladas como casos de uso en UML, tal como se muestra en el diagrama.

casos de uso

Diagrama de casos de uso para el sistema de venta

Los Requerimientos Funcionales

Normalmente los casos de uso son iniciados por algún actor, conocido como actor primario. Lo inicia con algún evento, que podría ser tan simple como elegir una opción en el sistema, y continúa como una serie de eventos o interacciones entre actores y sistema, hasta que el objetivo del caso de uso se cumple (el objetivo principal del caso de uso es lo que le da el nombre al mismo). Por lo tanto los casos de uso describen la funcionalidad del sistema para alcanzar objetivos importantes.

Lo que estamos obteniendo así es una especificación de requerimientos funcionales mediante un análisis top-down (de lo general a lo particular), es decir, primero obtenemos los objetivos que hay que cumplir en el sistema descritos con el nombre del caso de uso (p. ej: Realizar una venta) y después buscamos cuáles son las funciones o requerimientos funcionales precisos y ordenados para que el actor cumpla dicho objetivo al utilizar sistema. Esto nos lleva a identificar requerimientos realmente relevantes para alcanzar la misión del sistema.

Resumen para recopilar los requerimientos funcionales adecuados del sistema mediante casos de uso:

1. Especificar la misión del sistema
2. Identificar quiénes utilizarán el sistema (actores primarios)
3. Averiguar cuáles objetivos desean cumplir los actores al usar el sistema (casos de uso)
4. Identificar los pasos o eventos de cada caso de uso (especificación del caso de uso)


Las Interfases del Sistema

Hay otro tipo de actores que también hay que modelar; los actores secundarios. Suelen ser otros sistemas, componentes externos o dispositivos con los cuales interactúa nuestro sistema. A diferencia de los actores secundarios, éstos no son los que inician o requieren del caso de uso, sino que nuestro sistema, al llevar a cabo un caso de uso requiere tener algún tipo de interacción con él.
En el diagrama de casos de uso también suele ser apropiado mostrar a este tipo de actores, en cuyo caso aparecerán asociados a los casos de uso durante los cuales tienen que intervenir con algún tipo de interacción con el sistema a modelar.

Ejemplo de Actor Secundario

Nuestro sistema de ventas podría requerir enviarle información al sistema de contabilidad cuando se ejecuta la funcionalidad del caso de uso “Generar factura”. En dicha situación el sistema de contabilidad aparecerá como un actor secundario asociado a dicho caso de uso. De esta forma estamos mostrando las interfases requeridas con otros sistema en cada momentos.

Por experiencia sabemos que, en los modelos de UML, el buen uso de pocos elementos da mejores resultados que el uso de muchos elementos mal aplicados. La esencia de los modelos radica en la simplicidad, ya que facilita el análisis, entendimiento y comunicación entre quienes solicitan el sistema y los que participan en su desarrollo.
En otras oportunidades veremos elementos adicionales para modelar los casos de uso, pero podemos asegurar que la sencillez es parte importante del modelado, y esto implica que en ocasiones, y sobre todo cuando el analista no tiene tanta experiencia en UML, es mejor limitarnos a los elementos más básicos.

Por Sergio Orozco.

 

<< Regresar a artículos



Contacto
.
.
México D.F. - +52 (55) 5594 6411
  Envíanos un E-mail a:
cursos@abiztar.com.mx
.
O si lo prefieres:
Llena nuestro formulario de contacto
  [ Aviso de privacidad ]

© Abiztar. PMI, PMBOK, OPM3, CAPM, PMP, PMI-SP y PMI-RMP son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. Capability Maturity Model y CMM son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon. CMM, IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA, BPMN, SysML, MOF, OMG y UML son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP es una marca registrada por IBM Corp."