Buscar en Gazafatonario IT

martes, noviembre 06, 2012

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, IV


Al escribir el caso de uso deben evitarse sinónimos “técnicos” para Sistema como “programa”, “módulo”, “rutina”, “función”, “procedimiento”, “procedimiento almacenado” y “subrutina”. Como en:
n. El programa solicita la fecha de ingreso
n+1. El actor proporciona la fecha de ingreso
n+2. El módulo calcula el número de días laborados hasta la fecha
Algunos de estos términos son usados de manera indistinta donde debemos usar siempre “sistema”, otros se usan en pasos específicos donde normalmente estamos suministrando información técnica que no es responsabilidad de los casos de uso, como cuando hablamos de procedimientos almacenados o de rutinas.
Simplemente usamos el término “sistema”.
Ejemplo
Consideremos el siguiente caso de uso de la Web 2.0, relacionado con la publicación de entradas en un blog:
Caso de Uso: Publicar Artículo
Actor: Bloguero
Descripción: este caso de uso permite crear una entrada para su publicación en un blog específico de la Web.
Precondiciones:
1.     El Bloguero está debidamente acreditado ante el Sistema
Secuencia Básica:
1.     El caso de uso inicia cuando el Bloguero opta por publicar un nuevo artículo
2.     El sistema solicita el título del artículo
3.     El Bloguero ingresa el título del artículo
4.     El sistema solicita el cuerpo del artículo
5.     El Bloguero proporciona el cuerpo del artículo
6.     El sistema solicita las palabras clave con las cuales indexar el artículo
7.     El Bloguero ingresa las palabras clave del artículo
8.     El sistema verifica que el título del artículo no existe y solicita confirmación para publicar la entrada
9.     El Bloguero confirma la publicación del artículo
10.   El sistema publica el artículo
11.   El caso de uso termina
Secuencia Alterna 1: el título de la publicación ya existe
8A. El sistema muestra el mensaje “El título del artículo ya existe. Por favor, verifique.”
8B. El caso de uso continúa en el paso 2 de la secuencia básica
Secuencia Alterna 2: el Bloguero cancela la publicación del artículo
9A. El Bloguero cancela la publicación de la entrada al Blog
9B. El caso de uso termina
Poscondiciones:
1.     La entrada se puede modificar durante los siguientes 30 minutos.
2.     El artículo puede ser leído por los lectores del blog.
Nótese que en todo momento sabemos qué hace el sistema y qué hace el actor.

domingo, noviembre 04, 2012

Diez Consejos Útiles y Simples Para Escribir Efectivamente Casos de Uso Efectivos, III


Puesto que es una buena (mejor) práctica encontrar primero los actores y a continuación los casos de uso, es recomendable también especificar el actor en la descripción de cada paso, en vez del término genérico “actor”, como en:
q. El sistema solicita la fecha de creación de la cuenta
q+1. El Analista de Crédito ingresa la fecha de creación de la cuenta
Recordemos que los actores, humanos o no, son externos a y delimitan el sistema y, por tanto, su funcionalidad. Es a los actores a quienes les interesa el resultado de cada caso de uso, cualquier proceso del sistema, así sea un proceso automático, ocurre porque en algún instante a alguien o a algo consultará o le resultará de vital importancia el resultado de ese proceso. Ningún caso de uso lo sería si no hay un actor involucrado, directa o indirectamente.
Con ello en mente, y ya que vamos a adoptar la rutina de identificar a cada actor del sistema y luego a los casos de uso subyacentes, en estos nombraremos al actor cada que ejecute una acción y no usaremos términos como “usuario”, “usuario final” o “actor”.
Ejemplo
Consideremos un caso de uso simple para consultar el saldo disponible en una cuenta bancaria vía Internet:
Caso de uso: Consultar saldo
Actor: Cuenta-habiente
Precondiciones: El Cuenta-habiente está debidamente autenticado ante el sistema virtual
Secuencia básica:
1.     El caso de uso inicia cuando el Cuenta-habiente quiere consultar el saldo disponible en su cuenta de ahorros
2.     El sistema solicita seleccionar la cuenta
3.     El Cuenta-habiente selecciona la cuenta de la cual consultar el saldo
4.     El sistema consulta la cuenta y muestra el saldo disponible
5.     El caso de uso termina
Poscondiciones: Él Cuenta-habiente puede transferir dinero a otra cuenta. El Cuenta-habiente puede hacer pagos a terceros.
El correcto nombramiento de los actores también ayuda a entender mejor el sistema que vamos a construir. Un banco, por ejemplo, tiene muchos tipos de clientes, algunos de estos tienen abierta una o más cuentas bancarias tradicionales, son los Cuenta-habientes. Al menos en Colombia, una persona puede tener una tarjeta de crédito emitida por un banco o un crédito de consumo y no tener ningún otro producto con la entidad financiera, son otros tipos de clientes, por lo que usar el término genérico Cliente no ayuda mucho.
Nótese en el caso de uso la especificación de precondiciones y poscondiciones que, entre otras características, hacen más clara y corta la especificación y permiten a los involucrados conocer más detalles de la operación que se está describiendo.

viernes, noviembre 02, 2012

Ecos del Simposio Latinoamericano de Ingeniería de Software



Aunque ya pasó algún tiempo desde que escribí este artículo, el tema de Semat está cobrando vida y afectará el futuro de la Ingeniería de Software como la conocemos hoy. Por consiguiente, impactará en la manera cómo hacemos Ingeniería de Requisitos, en particular, y el universo de los métodos de software en general.

Este es un brevísimo resumen de lo que pasó durante los dos días del simposio: los temas expuestos, la presencia del experto internacional Ivar Jacobson, la creación del capítulo para Latinoamérica de la iniciativa SEMAT, una revolucionaria propuesta que el mismo Jacobson apoya junto a otros prominentes miembros de la industria del software y que busca refundar la ingeniería de software con una teoría sólida, principios probados y mejores prácticas refinadas.

El artículo completo lo pueden descargar en:



https://docs.google.com/file/d/0B5SNac-eZKMMdGY2V2xZVnFtQXc/edit?usp=sharing

El sitio de Semat Central es: http://www.semat.org.

jueves, noviembre 01, 2012

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, II


Siempre que sea posible, debemos evitar secuencias de pasos como:
n. El sistema hace…
n+1. El sistema hace…
O
m. El actor hace…
m+1. El actor hace…
Donde n y m son números de pasos de una secuencia cualquiera del caso de uso. Es decir, ni el sistema ni el actor ejecutan dos pasos seguidos en el caso de uso. La escritura de casos de uso debe (ría) obedecer al siguiente patrón de diálogo:
p. El sistema hace…
p+1. El actor hace…
Donde “hace” se debe reemplazar por la acción que uno y otro ente realizan. Normalmente, el sistema “solicita” el ingreso o selección de datos y el actor “proporciona” datos, ya sea ingresándolos (por medio del teclado, en cuyo caso “digita” los datos) o seleccionando uno o más datos disponibles de una lista suministrada por el sistema. Nunca se debe especificar el mecanismo programático (formularios, ventanas, cuadros de texto, listas combinadas, cuadros de chequeo, botones de comando, entre otros) utilizado para crear y mostrar la lista. Ejecutar.
Además, nuestros usuarios siempre esperan que los sorprendamos con algo novedoso y una forma mejor de hacer las cosas. En el futuro cercano, por ejemplo, esperarían no tener que lidiar con la clásica interfaz gráfica de hoy sino con hologramas u otra suerte de mecanismos de comunicación Humano-Máquina. Pero ese es otro asunto.
Volviendo al consejo práctico que nos ocupa, normalmente cuando ocurre que debemos especificar varias actividades seguidas de un actor o del sistema, nos encontramos ante una de estas situaciones: estamos haciendo descomposición funcional que, en principio, es innecesaria. Recordemos que lo esencial en un caso de uso es especificar lo que hace el sistema que es relevante para el negocio o para ese actor en particular. Por ejemplo, para un actor es significativo que el sistema busque y muestre los datos de una factura o le indique que no la encontró, pero no es importante si esa búsqueda ocurre mediante un método secuencial, uno binario, la técnica de Fibonacci o un algoritmo genético, o si usa el mismo método de google para encontrar páginas en Internet.
También puede ocurrir que estamos especificando una funcionalidad del sistema que es posible documentar mejor con otros mecanismos como diagramas de actividad o estado o, si es necesario documentación textual, con requisitos escritos a la usanza tradicional de: “el sistema debe hacer algo…”. También se pueden usar escenarios, tableros de historias (storyboards), prototipos o simuladores, o una combinación de dos o más de estos artilugios.
Ejemplo
El siguiente caso de uso para reservar sillas en un viaje por avión nos ilustra muy bien esta sugerencia:
Caso de Uso: Reservar tiquetes
Actor: Cliente (Aerolínea)
Secuencia Básica:
1.    El caso de uso inicia cuando el Cliente decide reservar tiquetes aéreos
2.    El sistema solicita seleccionar la ciudad origen
3.    El Cliente selecciona la ciudad origen
4.    El sistema solicita seleccionar la ciudad destino
5.    El Cliente selecciona la ciudad destino
6.    El sistema solicita la fecha de ida
7.    El cliente ingresa la fecha de ida
8.    El Sistema solicita la fecha de regreso
9.    El Cliente ingresa la fecha de regreso
10.  El sistema solicita el número de pasajeros
11.  El cliente ingresa el número de pasajeros
12.  El sistema verifica que hay disponibilidad de vuelos entre las ciudades y fechas solicitadas
13.  El sistema verifica que hay disponibilidad de asientos para el número de pasajeros establecidos
14.  El sistema muestra el mensaje “Sí hay disponibilidad de vuelos  entre las ciudades y fechas establecidas”
15.  El sistema genera un número de reserva
16.  El sistema almacena la información de la reserva
17.  El caso de uso termina
Aquí caímos en la típica descomposición funcional que se debe evitar durante la etapa de requisitos. Los pasos 12 a 17 bien pueden reemplazarse por:
12. El sistema verifica que hay asientos disponibles y muestra el número de reserva.
13. El caso de uso termina
¿Y qué se hicieron las otras especificaciones? ¿Será que los programadores son capaces de inferirla? No. Estos otros detalles pueden documentarse como requisitos especiales en el caso de uso o como elementos de diseño (por ejemplo, estableciendo en un diagrama de secuencia cuáles son las entidades de almacenamiento de información o el algoritmo para generar el número de la reserva). Nótese que estos aspectos no son relevantes para el negocio.

lunes, octubre 29, 2012

Diez Consejos Útiles y Simples Para Escribir Correctamente Casos de Uso Correctos, I


“Todo debería hacerse lo más simple posible, pero no más simple.”
Frase atribuida a Albert Einstein
Presentación
Un caso de uso es un protocolo, en el sentido de conversación, normalmente entre un ser humano y un sistema de software y, como cualquier conversación en idioma español, debe ser fluida, sin tropiezos, en la que se usen términos y expresiones familiares o entendibles por los participantes. Durante esa charla, el sistema “solicita de”, “proporciona a”, o “procesa[1] información para”; mientras tanto, la persona que actúa como interlocutor suministra a, o requiere de, información. Es así de simple.
Ahora bien, la especificación de un caso de uso es una historia que escenifica las distintas situaciones que se pueden presentar en el diálogo antes mencionado. Y como historia, debe contarse de manera directa, sin adornos (adjetivos) y con objetividad. El autor del caso de uso, normalmente un Ingeniero de Requisitos, debe mantenerse al margen de los hechos, no debe hacer comentarios o dar explicaciones (sus percepciones) al respecto, no debe involucrarse en la historia.
Con todo lo anterior en mente, les traigo estos diez consejos que espero sean muy útiles a la hora de especificar requisitos de software vía casos de uso. Son lecciones que he aprendido con el tiempo y con la práctica y que me han funcionado bastante bien.
Consejo 1
Al escribir casos de uso se deben evitar términos como:
·         Automáticamente
·         Procesar
·         Administrar
·         Gestionar
Y sus sinónimos.
Automáticamente, relativo a automático,  se refiere a una cualidad que todos los sistemas tienen de manera intrínseca, que está en la naturaleza del software, ya que este sigue a determinadas circunstancias de un modo inmediato y la mayoría de las veces indefectible, es decir, cualquier cosa que hace el software es iniciada por un impulso externo, incluyendo los llamados “procesos automáticos” cuyo inicio obedece muchas veces al cumplimiento de una condición de tiempo, o sea, se ejecutan a una hora específica programada por una persona, o a un prerrequisito, es decir, otra acción o proceso se llevó a cabo y preparó los insumos necesarios para la tarea siguiente. Siempre hay un estímulo que precede a la acción automática.
Entre tanto, Procesar es una expresión genérica, abstracta por demás, que indica cualquiera de las operaciones que puede hacer un sistema de software y siempre debe reemplazarse por el nombre de la operación particular a la que queremos referirnos. Por ejemplo, hacer un cálculo, realizar una búsqueda, clasificar datos y almacenar datos. Ahora bien, es posible que el sistema realice más de una de estas acciones al tiempo o haga una combinación de varias de ellas, pero este es un asunto que abordaré en el consejo número seis.
Por su parte, Administrar y Gestionar son sinónimos entre sí y, al igual que Procesar, son comodines en el sentido de que sirven para acomodar cualquier acción o manipulación sobre la información; siempre debemos nombrar explícitamente la acción, como Transferir o Enviar, Recibir, Validar una condición específica y Generar o Mostrar datos, o el tipo de manipulación, como Ingresar, Modificar, Eliminar y Consultar datos.
Ejemplo
Consideremos el siguiente caso de uso típico para ingresar a un sistema transaccional con seguridad simple:
Caso de Uso: Ingresar al sistema
Actor: Cliente
Secuencia Básica:
1.     El caso de uso inicia cuando el Cliente decide autenticarse ante el sistema
2.     El sistema solicita el nombre de usuario del Cliente
3.     El Cliente ingresa el nombre de usuario
4.     El sistema solicita la contraseña del Cliente
5.     El Cliente ingresa su contraseña
6.     El sistema procesa el nombre de usuario y la contraseña y presenta un mensaje de bienvenida
7.     El caso de uso termina
En esta secuencia, el paso 6 debe modificarse por algo como:
6. El sistema verifica la información proporcionada y presenta un mensaje de bienvenida.
Nótese que este es el escenario “feliz” donde los datos ingresados por el usuario son correctos y el sistema permite su ingreso al sitio transaccional. Aquí “verifica” es sinónimo de “comprueba” o “identifica”, un significado más directo que el derivado de “procesa” en el caso de uso original.

[1] Estoy usando “procesar” en un sentido amplio, significando cualquiera de las funciones comunes que desempeña un computador, como calcular, buscar u ordenar datos, o una combinación de dos o más de estas.

miércoles, octubre 24, 2012

Gerencia de Proyectos Dirigida por Riesgos: la estrategia del Maestro de ajedrez


No me gustan los artículos sobre Gerencia de Proyectos. Casi todos siguen la receta de “Cómo hacer esto o aquello”, “Cómo escribir un artículo de gerencia de proyectos”: 1) encuentra un tema sobre el cual escribir, donde incluso te dicen que puesto que eres un gerente de proyectos, trata el proceso de escribir el artículo como un proyecto; 2) organiza tu artículo, donde debes planear el alcance y ejecutar el plan, es decir, escribir la crónica y, por supuesto, cerrar el proyecto, que se traduce en publicar el artículo. Y luego te dan ideas de cómo mejorar el artículo y cosas así. De hecho, existen las recetas para que mantengas la certificación como PMP (PMI) escribiendo artículos sobre gerencia de proyectos “¡y ganas 15 créditos PDU!”

Y los que no son así, son escritos por autores cuyos proyectos han sido todos fallidos y quieren que nosotros no cometamos los mismos errores que ellos. Estos autores nos dicen precisamente que cuando llegaron al fondo, tuvieron una epifanía que ningún otro ser humano tuvo hasta entonces, así es que decidieron compartir su experiencia divina con el resto de los mortales. Son reseñas usualmente repetitivas, simples y, algunas, hasta absurdas.

Por eso no me gustan esa clase de trabajos, pero este artículo que les voy a recomendar, sobre gerencia de proyectos, tiene la palabra “paritariamente”. ¿Qué significa “paritariamente”? Eso quizás no es importante, el asunto realmente interesante es que este artículo tiene palabras de más de tres silabas y frases con sentido completo, de esas que aprendíamos mientras leíamos a los Clásicos antiguos o a Don Quijote de la Mancha. Este artículo se atreve a mencionar el juego de Ajedrez y hace una comparación entre la mente de los gerentes de proyectos y la de los grandes maestros del juego ciencia, habla de estrategia y la diferencia de la táctica, habla de la anticipación (palabras de más de tres silabas) y presenta el análisis pre-morten (frases con sentido completo), es decir, de prever algo y manejarlo antes de su ocurrencia.

Incluso este artículo se atreve a desmentir la muy archi-popular Ley de Murphy y nos presenta la primera Ley Anti-Murphy o Ley de la Proactividad, inclusive se atreve a decir que la mejor herramienta de administración de proyectos no es un sistema de software. El artículo va más allá de las herramientas automatizadas y le otorga confianza a la mente humana (la mente de los grandes maestros).

Por eso me gusta este artículo, llamado “Gerencia de Proyectos Dirigida por Riesgos: la estrategia del Maestro de ajedrez”. El artículo lo encuentran en el portal especializado LiderdeProyecto.com, en la dirección:

http://www.liderdeproyecto.com/articulos/gerencia_de_proyectos_dirigida_por_riesgos_la_estrategia_del_maestro_de_ajedrez.html

Ah, se me olvidaba decirles, yo soy el autor del artículo. ¡Por eso también me gusta!

jueves, octubre 11, 2012

Los casos de abuso o de cómo hacer un mal uso de los casos de uso


Este fue un estudio de hace unos 5 años. Los resultados los publiqué entonces internamente como la Lectura Fundamental 13, que nunca vio la luz en este Gazafatonario. Solo ahora, revisando los temas que incluiré en mi próximo libro, decidí hacerlos público abiertamente como ustedes los han estado leyendo.
No obstante el tiempo que ha pasado desde entonces, el resultado de mi observación es que seguimos cometiendo estos errores incontables veces. Por eso no quise esperar a que el libro estuviera publicado.
Lo primero que se deriva de este análisis es que los casos de uso no son el único instrumento para especificar requisitos de software, algo que he llamado en otras instancias “el arquetipo de los envoltorios heterogéneos”.
Pero antes de ir a la conclusión de este estudio, revisemos los abusos que estamos cometiendo:
Caso de Abuso
Impacto en la Calidad
Alto
Bajo
Medio
Medio
Medio
Alto
Bajo
Alto
Bajo
Alto
Alto
Medio
Hay muchos más: el problema es mucho más grave cuando no hay el entrenamiento y acompañamiento que todo Analista o Ingeniero novel necesita cuando emprende el viaje hacia lo que significa identificar, documentar, organizar y administrar requisitos de software.
Para No Cometer Más Abusos
En general, las personas creemos que el mejor proceso de aprendizaje es la lectura. Si bien es cierto que leer es fundamental, sobre todo en las etapas tempranas de la carrera de un buen profesional, pienso que la forma principal de aprendizaje es la introspección. Leer siempre ayuda, especialmente porque puede hacernos reflexionar sobre puntos que no habíamos analizado previamente, pero la mejoría como Analista de Requisitos en particular y como Ingeniero de Software en general, más allá de un ingeniero primitivo que hace su trabajo con las prácticas regulares transmitidas por instructores académicos que muchas veces nunca han estado en un proyecto de construcción de software, empieza siempre por el análisis profundo de cada situación. Conocer nuestras debilidades y saber por qué estamos haciendo en cada situación lo que estamos haciendo, es lo que nos acabará convirtiendo en mejores profesionales. Y para eso, aprender de los propios errores es algo esencial, tratando de evitar automatismos que pueden repercutir negativamente en nuestra profesión.
En particular, recomiendo leer a Cockburn [11] de quien ya he repetido es uno de los mejores autores de temas relacionados con la materia que nos ocupa: la escritura de casos de uso. El libro tiene un capitulo completo sobre errores cometidos al momento de escribir casos de uso. Pero también encuentro de mucha utilidad volver a leer y a releer los casos de uso que hemos escrito anteriormente. Y leer los casos de uso de nuestros compañeros. Someter los nuestros al escrutinio de nuestros pares y de otros expertos en el área, recibir con respeto las observaciones que nos hacen y discutirlas abiertamente. Leer las guías y listas de chequeos existentes y seguir las indicaciones de las plantillas ayuda profusamente. Para noveles, recomiendo las cinco primeras lecturas fundamentales de mi Gazafatonario IT [13] (Gazafatonario.Blogspot.com).
El artículo que motivó este estudio lo leí hace unos 13 años [14], lo encargo pródigamente. En [12] hay un compendio expedito sobre la cuestión, a manera de enumeración ejecutiva sobre lo malo y lo feo en las prácticas de casos de uso. De la misma forma, en [7] hay unas guías para cometer abusos, por supuesto, debemos usarlas a la inversa. Finalmente, en [15] y en [10] Ellen Gottesdiener identifica algunos patrones de abuso que siguen los equipos de desarrollo a la hora de crear casos de uso; no puede faltar en nuestra biblioteca digital de consulta. Por su parte, en [16] encontramos algunas sugerencias para aplicar durante el entrenamiento de estudiantes y profesionales en el área de Requisitos de Software, específicamente en modelado y especificación de casos de uso.
Y mi última recomendación: ¡Lanzarnos! Es decir, escribir casos de uso.
(Aclaración)
A propósito de todos estos trabajos relacionados que especifico en la sección anterior, cuando hacía la labor de investigación de fondo sobre este tema (paso 2 del método científico), me encontré inexorablemente en Google buscando por los términos “abuse cases” y “misuse cases” y Oh sorpresa mayor cuando me topé con [8] y [9] y el contexto es totalmente distinto al que deseaba: resulta que un caso de abuso (“abuse case”) es una especificación de un tipo de interacción completa entre un sistema y uno o más actores, donde los resultados de la interacción son dañinos para el sistema, para uno de los actores o para uno de los involucrados (stakeholders) en el sistema. Seguí este hilo y encontré todo un sumario que habla de modelos de casos de abuso para hacer análisis de requisitos de seguridad y de casos de uso con intención hostil (hacia los sistemas de software), no sólo en cuanto a la seguridad de las aplicaciones se refiere sino a los demás requisitos “ilidad” (confiabilidad, mantenibilidad, soportabilidad, funcionalidad y otras “ilidades” conocidas).
Así es que me pareció pertinente contarles el cuento por si llegan al punto o por si llegan a necesitar el dato. No es más.
Conclusiones
Errores se cometen en cualquier actividad, incluso he llegado a creer que la propia Naturaleza se equivocó al seleccionarnos como especie dominante durante este período cuaternario de la era Cenozoica, pero ese es otro asunto. Sin embargo, de los errores se aprende y, al parecer, estamos preparados para aprender muy rápido de nuestros propios sofismas. Es por eso que quise traerles este vademécum que espero se convierta en material de consulta regular y que apoye al elemento sorpresa asociado al descubrimiento de que estamos equivocados, para que así podamos formarnos en el difícil oficio de la Ingeniería de Requisitos y afines.
Sin duda, la lista de faltas puede ser mayor, pero lo que hacemos no define quienes somos, lo que nos define es qué tan bien nos levantamos después de caernos; es decir, lo que hacemos después de cometer la infracción. Algunos de estos abusos son más graves que otros, no tanto para nosotros, individuos reemplazables, sino para nuestros receptores principales: los usuarios.
Referencias
Algunas de estas referencias “bibliowebgráficas” ya las he mencionado en cada uno de los casos de abuso. Aquí están todas en conjunto para su consulta:
[1]  P.B. Kruchten, “The 4 + 1 View Model of Architecture,” IEEE Software, pp. 42–50, Nov. 1995. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=469759&isnumber=9910
[2]   Luis Antonio Salazar Caraballo, “RUP: Fase de Concepción”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2007/03/lecturas-fundamentales-8.html, 08 mar. 2007.
[3]  Luis Antonio Salazar Caraballo, “Realización de Casos de Uso: de los Objetos y sus Interacciones”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2007/10/lecturas-fundamentales-10-lectura_3046.html, 23 oct. 2006.
[4]  Luis Antonio Salazar Caraballo, “Casos de Uso: Del Todo y de Sus Partes”, Gazafatonario IT,  http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales-3.html, 23 nov. 2006.
[5]  Así conocen al célebre trío de metodólogos que lideraron la creación de RUP y UML: Ivar Jacobson, James Rumbaugh y Grady Booch.
[6]  Luis Antonio Salazar Caraballo, “Casos de Uso: Origen, Especificación y Evolución”, Gazafatonario IT, http://gazafatonarioit.blogspot.com/2006/11/lecturas-fundamentales-2.html, 17 nov. 2006.
[11]Alistair Cockburn, “Writing Effective Use Cases”, Addison-Wesley, 21 Feb. 2000
[17]Real Academia de la Lengua Española. RAE. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=abuso