Please enable JavaScript.
Coggle requires JavaScript to display documents.
Diagramas para la especificación y análisis de requisitos - Coggle Diagram
Diagramas para la especificación y análisis de requisitos
Lenguaje Unificado de Modelado UML
UML (Lenguaje de Modelado Unificado) facilita el diseño de sistemas orientados a objetos mediante normas gráficas que representan su estructura y funcionamiento.
Permite a los creadores de sistemas generar diseños que capturen sus ideas en una forma convencional y fácil de comprender para comunicarlas a otras personas
La primera versión oficial UML 1 se lanzó en el año de 1997. Su principal objetivo es que todos los diagramas tengan coherencia. En el año 2005 se divulgó la versión de UML 2.0 cuyo contenido estaba orientado principalmente a la visión Orientada a Objetos, de ahí en adelante se realizan nuevas versiones basadas en UML 2.0.
UML es un lenguaje capaz de brindar unas reglas que facilitan la comunicación de un sistema por medio de representaciones gráficas de este, indicando como hacer la creación y la lectura de los modelos.
Características generales del Lenguaje Unificado de Modelado (UML)
Visualizar
UML facilita la representación de un sistema de forma gráfica con el fin de que se pueda entender fácilmente por otra persona.
Especificar
UML permite detallar cuáles son las necesidades de un sistema previo a su construcción.
Construir
La contrucción del sistema diseñado se realiza tomando los modelos especificados en el lenguaje UML
Documentar
Cuando se diseñan las notaciones gráficas del sistema desarrollado estos se usan como documentación la cual permite soporte para nuevas revisiones o empalme para que nuevos desarrolladores entiendan el sistema.
Las características del UML se aplican en las fases de Desarrollo de Software, la primera fase es la de análisis y especificación de requisitos.
Especificación y análisis de requisitos
La función más importante de la Especificación de Requisitos es servir de intermediario para que los clientes, los analistas de requisitos, desarrolladores y los usuarios puedan comunicarse.
En esta es fundamental recolectar tanto los requerimientos de usuario y del cliente como los del software a desarrollar para lograr la satisfacción del cliente
Cuando se realiza la recolección de requerimientos de un cliente, UML por medio de sus casos de uso permite el modelado de estos requerimientos.
Quienes especifican los requerimientos de un cliente son los casos de uso y sus actores, qué es la expectativa que cada uno tiene del sistema, sin tener en cuenta la funcionalidad que se realizará.
Los análisis de requisitos se realizan para diferentes procesos no necesariamente para desarrollos de software.
Entre los diagramas más relevantes (y más utilizados) que se encuentran en UML están los diagramas de casos de uso.
Diagramas de caso de uso
Los casos de uso describen las funciones del software desde el punto de vista del usuario. Expresan las funcionalidades y definen quién las ejecutará, mediante diagramas con notación específica, representando el comportamiento del software en la interacción con el usuario para alcanzar objetivos.
Componentes
Se compone principalmente de 3 elementos que ayudan a representar simbólicamente las funcionalidades, personas involucradas y relación entre estas y los cuales son:
4 more items...
Relaciones de caso de uso
En el desarrollo, los casos de uso no son independientes; pueden establecerse relaciones de dependencia entre ellos.
1 more item...
Especificación de casos de uso
Cuando se habla de especificación de casos de uso se hace referencia al proceso de descripción textual de cada uno de estos detallando los flujos y eventos que interactúan con el sistema y los actores que participan en él
1 more item...
https://www.academia.edu/4218624/Material_Casode_Uso
Descripción de una especificación de caso de uso
9 more items...
Casos de uso reales (prototipos)
Su objetivo principal es detallar el proceso de un sistema de información que se describe por medio de un caso de uso incluyendo la interacción de objetos, así como definir las transacciones de las interfaces y clases de los diferentes procedimientos secundarios de diseño.
1 more item...
Historias de Usuario
Las historias de Usuario son una forma sencilla de representar los requisitos de un sistema de información, son creadas en una o dos oraciones y sobre todo escritas en un lenguaje muy común y legible para el usuario.
Son llamadas User Stories, convirtiéndose en un estándar muy utilizado en el momento de la definición de requisitos.
las historias de usuario están compuestos de 3 elementos que se describen a continuación.
Tarjeta (Card)
Es una frase que sintetiza una necesidad dada en una conversación entre el usuario y el dueño del producto, escrita en una tarjeta, es comúnmente usada en el formato rol-objetivo- beneficio
Su estructura es:
Como [tipo de usuario] -> ¿quién?
¿Se sabe quién? (permite identificar los roles de valor).
Quiero [necesidad] -> ¿qué?
¿El qué? (permite identificar el problema que se resuelve)
Para [beneficio esperado] -> ¿para qué?
¿Para qué? (lo que se espera lograr con la construcción de la historia de usuario).
Conversación
Es el proceso en el que se comunica las personas que requieren las necesidades (dueño del producto) con las personas que saben cómo solucionarlas (desarrolladores)
esto se hace de la siguiente forma:
Por medio de preguntas
Utilizando recursos como: gráficas, prototipos etc.
ejemplo de “Compra una boleta de cine”: se realizarán las siguientes preguntas:
4 more items...
Confirmación
Cuando se realizan historias de usuario es muy importante cumplir con las siguientes reglas:
Ser concisa
Una buena guía para redactar Historias de Usuario con calidad es seguir el acrónimo INVEST, como se muestra a continuación:
I
1 more item...
N
1 more item...
V
1 more item...
E
1 more item...
S
1 more item...
T
1 more item...
Utilizando este método se logra asegurar que una historia de usuario no sea dependiente de otra y así poder proporcionar que su planificación y desarrollo no incluya muchos datos técnicos que restrinjan los convenios entre los clientes y los desarrolladores.
Plantillas historias
Concreta
Realizar criterios de aceptación claros y específicos
Plantillas de historias de usuario
Las plantillas de historias de usuario pueden ser adaptadas según las necesidades requeridas sin perder la flexibilidad y sencillez que ofrece una HU, los equipos de desarrollo trabajan conjuntamente utilizando herramientas en línea para compartir y trabajar en las plantillas.
Ejemplo plantilla de historia de usuario
Las tres técnicas más utilizadas para la descripción de requerimientos son:
Los casos de uso
Las historias de usuario
Los diagramas de actividades.
Clic aquí para ver mapa conceptual de resumen del tema
Diagramas de actividades
Estos son diagramas de comportamiento
se utilizan para representar una sucesión de actividades
explican el flujo de operaciones desde el punto en que inician hasta el punto final definiendo una variedad de caminos de decisiones en el desarrollo de eventos que abarca una actividad.
Ellos permiten visualizar un caso de uso específico a un nivel más preciso, ilustrando el flujo de actividades definidas en un sistema.
Beneficios:
Permite explicar la lógica de un algoritmo.
Representa cada uno de los procesos realizados en los diseños de casos de uso en UML.
Permite instruir procesos entre el sistema y los usuarios en un flujo de trabajo o negocios.
Permite dar claridad optimizando y facilitando los casos de uso complejos.
Elementos de un diagrama de actividades
Un diagrama de actividades contiene fundamentalmente los siguientes elementos:
Actividad
Una actividad es la descripción o el detalle de una sucesión de conductas parametrizadas, se simboliza como un flujo de acciones ordenadas. El modelado de este flujo se hace por medio de nodos de actividad que se conectan por medio de flujos de control. Las actividades generan jerarquías de peticiones llamando a diferentes actividades o como último recurso solventando operaciones propias.
Flujo entre actividades
Este permite realizar los enlaces entre objetos y nodos de una actividad, estos agregan flujos de objetos y flujos de control. Su representación gráfica se hace por medio de una flecha con punta abierta que representa como es el orden en la ejecución de las actividades, muchas veces se adiciona una descripción en la flecha para una mejor comprensión.
Nodo inicial
se encarga de empezar un flujo, cuando se llama a una actividad, por cada diagrama existe un solo nodo inicial, el cual se representa con un círculo pequeño.
Nodo final
Su función es detener todos los flujos de una actividad, en una actividad pueden existir más de un nodo final. Este se representa con un círculo sólido con un hueco
Para profundizar en elementos de un diagrama de actividades seguir el link para mirar en YouTube
https://www.youtube.com/watch?v=GoYdpOVhDRc&list=PLM-p96nOrGcaw5dhv8wOA5tVVWEmXtA2F&index=17
Ejemplo de diagramas de actividades
Dar clic aquí para ver imagen
Como se muestra en el ejemplo anterior, el flujo inicia con la actividad autenticar usuario y pasa por un nodo de decisión que verifica si el usuario existe no o no, si el usuario existe pasa a un nodo de decisión donde valida el usuario y si no es correcto, muestra un mensaje de error, si es correcto da acceso a la aplicación y muestra el menú inicio.
En caso de no existir el usuario pasa a la actividad de registrar usuario y después ingresa datos, luego sigue a un nuevo nodo de decisión, donde valida datos y da acceso a la aplicación por lo que sigue el flujo de actividad mostrando la interfaz del menú del sistema y finalmente termina la actividad con un nodo final.
